Software Units

No contexto do licenciamento da Agile Platform (o produto desenvolvido pela Outsystems, a empresa onde trabalho) existe o conceito de Software Units* (SU) que são, de grosso modo, uma medida da complexidade das aplicações criadas e mantidas na Agile Platform. A Agile Platform usa uma abordagem gráfica para descrever como é que páginas de uma aplicação web devem ser criadas e uma linguagem simples de programação específica ao domínio para descrever a lógica das aplicações. As Software Units são calculadas atribuindo um valor a cada elemento da linguagem gráfica e somando-os todos.

Os pesos de cada elemento (1) são atribuídos de uma forma arbitrária mas que tem principalmente em conta quanto trabalho é que a plataforma poupa ao utilizador em relação com produzir e manter o código necessário para a funcionalidade numa linguagem de mais baixo nível (C# ou Java, para dar o exemplo das linguagens para as quais o nosso código é compilado). É por isso que uma pergunta simples à base de dados (Simple Query) vale 20 SU's enquanto uma pergunta avançada vale 2. No caso da pergunta simples, a plataforma gere coisas como só trazer os campos que são usados pela aplicação de forma a melhorar o desempenho (2), enquanto que numa pergunta avançada, embora se tenha maior poder expressivo, toda a gestão da pergunta tem de ser feita pelo programador, tal como seria numa linguagem de mais baixo nível.

Este meu post tem a ver com a nota que o Pedro Oliveira faz no post no fórum, em que ele diz para se "evitar a todos os custos desenvolver com o objectivo de minimizar o consumo de Software Units. Esta prática irá muito provavelmente conduzir a código de difícil manutenção com uma arquitectura torcida que destrói totalmente a razão para o uso da Agile Platform" (tradução minha).

Volta e meia aparece-nos lá na Manutenção (a equipa em que estou presentemente inserido) e nos fóruns exemplos retorcidos do uso da Agile Platform que têm obviamente (às vezes mesmo assumidamente) o intuito de "poupar Software Units". Temos clientes a perguntar porque é que referências a entidades no Integration Studio não estão a criar as entidades, ou clientes que fizeram perguntas avançadas quando uma simples chegava bem a queixar-se que o desempenho está mau. Tal como o Pedro avisou, estas práticas levam a código de difícil manutenção e à subversão total do objectivo pelo qual se usa a Agile Platform. Devido ao facto de ser mais caro programar "como deve ser" podemos estar a criar algum desconforto nos nossos clientes que se vêm forçados a usar estas técnicas pouco saudáveis para poupar uns trocos e que depois têm de manter o código que fazem porque não estão a tirar total partido da Agile Platform.

Há aqui claramente um conflito de interesses entre usar bem a Agile Platform e o quanto ela custa ao cliente. O cliente enfrenta o dilema entre fazer bom uso da Agile Platform e tirar o máximo proveito económico do produto que comprou. Visto de outra forma: ao mesmo tempo que nós, Outsystems, dizemos que se deve programar de uma certa forma na Agile Platform estamos a penalizar financeiramente quem o faz. E os clientes, confrontados com a escolha entre ter de pagar mais para continuarem a trabalhar e transformar umas perguntas simples em perguntas avançadas, usualmente vão escolher programar "mal". Especialmente nas gamas mais baixas da plataforma (a versão "Community" grátis, Edição Standard) onde estão mais limitados no que diz respeito a Software Units e não têm ainda uma fábrica aplicacional muito pesada.

A verdade é que quando confrontados com ter de gastar mais dinheiro, a maioria dos nossos clientes (o nosso alvo de mercado são especificamente empresas) vai estrebuchar o máximo que conseguir para o evitar. Quando esse ponto de pressão para adquirir uma nova versão da Agile Platform é através da quantidade de Software Units, pela maneira como se atinge esse limite, há uma maneira relativamente fácil de optimizar as aplicações de forma a serem mais baratas. Isto é detrimental para a Outsystems porque quem chega ao ponto de precisar de comprar uma versão acima por causa da complexidade da fábrica aplicacional tem uma hipótese para se safar de comprar a versão mais acima. Ainda pior que só ter essa hipótese é que a seguir vai ficar mais descontente com a Agile Platform se seguir essa hipótese, já que vai estar a usar elementos menos optimizados da linguagem que não só causam um deterioramento do desempenho das aplicações como também são de manutenção mais difícil.

Acho que nesta altura ninguém terá alguma dúvida sobre qual é o ponto deste texto, mas fica sempre bem enunciá-lo claramente e suportá-lo com mais um pouco de argumentação a favor (e não apenas enunciar pontos contra a abordagem actual, como no resto do texto). Pessoalmente acho que era proveitoso para todos os envolvidos (Outsystems e os seus clientes) que a contagem das Software Units fosse repensada de forma a promover boas práticas em vez da abordagem actual de tentar reflectir o valor que a Agile Platform oferece com o elemento da linguagem.

Eu até acho que faz sentido cobrar-se pelo trabalho que a Agile Platform tem, e até compreendo que se queira cobrar mais pela plataforma fazer mais. Mas a partir do momento em que estamos a cobrar por programar bem, os clientes chegam à altura em que deveriam simplesmente pagar mais e têm a hipótese de programar mal para adiar esse facto. Acho que a maneira de contar Software Units que proponho (penalizando o uso de perguntas avançadas, por exemplo) iria não só fazer com que se programasse "melhor" como a abordagem preferida, como também tinha a vantagem de que quando se batessem nos limites de Software Units as hipóteses que apresentamos aos são pagar mais ou melhorar as aplicações. Na realidade quem chega a este ponto e já esteve a seguir as nossas recomendações de como programar, a única hipótese que tem seria comprar uma versão que permitisse mais Software Units. Assim, o que ensinamos nos bootcamps ajuda a fazer mais com a Agile Platform em vez de haver uma alternativa mais barata. Se os clientes chegam ao limite de Software Units e tiraram o máximo partido da Agile Platform e ainda por cima fizeram mesmo bastante com ela, é espectável que fiquem mais satisfeitos com o produto que oferecemos e que se sintam menos relutantes em adquirir mais Software Units.

Outro aspecto que consideraria uma vantagem desta abordagem é que certamente que surgiria uma pressão para criar elementos da linguagem para os usos mais comuns das perguntas avançadas que não podem ser concretizados com perguntas simples. A verdade é que havendo uma maneira barata de fazer alguns padrões de perguntas está a eliminar a pressão para desenvolver a linguagem da Agile Platform de forma a suportar estas perguntas à base de dados. Se usar perguntas avançadas fosse mais caro do que usar perguntas simples (ou outros elementos mais promovidos da linguagem) era certo que haveria pressão para se criarem elementos da linguagem específicos para essas situações, o que só tornaria o produto que oferecemos ainda melhor do que já é.

(1) How do we count Software Units? (Pedro Oliveira - Fóruns Outsystems)
(2) O que distingue um bom programador? (Canto do ardoRic)

* Vou manter a terminologia em inglês embora contraste um pouco com o resto do texto em português