Um conto de dois valores
Todo software fornece dois valores diferentes para os stakeholders: comportamento e estrutura. Os devs são responsáveis por manter ambos os valores altos, mas na maioria dos casos, um dos dois é sacrificado.
Comportamento
O primeiro valor é o comportamento. Devs são contratados para fazer com que as máquinas sejam eficientes para os stakeholders.
Arquitetura
A palavra software foi designada para descrever que um produto que seja flexível para mudanças. Para cumprir com essa expectativa, é necessário que um software tenha uma arquitetura robusta, que suporte mudanças de escopo e novas demandas, de forma que o custo de uma mudança não fique inviável durante a vida do software.
O valor maior
Função ou arquitetura?
Qual desses dois fornece mais valor a um software? É mais importante funcionar ou que seja fácil mudar?
Normalmente os desenvolvedores priorizam a decisão do gerente de negócios: que funcionem!
Segundo o Tio Bob, normalmente é a decisão errada. Eis o porquê:
“Se você me der um software que funcione perfeitamente, mas seja impossível de mudar, então ele não funcionará quando as exigências mudarem e eu não serei capaz de fazê-lo funcionar. Portanto, o programa será inútil.”
“Se você me der um software que não funcione, mas que seja fácil de mudar, então eu posso fazê-lo funcionar, e posso mantê-lo funcionando na medida em que as exigências mudarem. Portanto, o software permanecerá continuamente útil”.
Você pode não achar esse argumento convincente porquê você acha que não existe isso de um software ser impossível de mudar. Contudo, conforme um sistema cresce, a entropia e amarrações dele crescem com ele. Cada mudança gera uma necessidade crescente de avaliações de impacto. Você muda uma string e três sistemas/fluxos são afetados. O custo da mudança excede o benefício.
Entenda que: os gerentes querem as funcionalidades, mas ao mesmo tempo, querem ser capazes de arcar com os custos delas. No longo prazo e para sistemas complexos, só um dos dois valores possibilitará alcançar isso.
Considere estudar a matriz de eisenhower.
importante + urgente | importante + não urgente
não importante + urgente | não importante + não urgente
Se tratando dos dois valores:
Comportamento: urgente mas nem sempre é particularmente importante;
Arquitetura: importante, mas nunca é particularmente urgente.
Considerando a seguinte disposição de prioridades:
Urgente e importante;
Não urgente e importante;
Urgente e não importante;
Não urgente e não importante.
A arquitetura está nas duas primeiras posições da lista. Enquanto o comportamento ocupa a primeira e a terceira posição.
O erro que gerentes e devs cometem com frequência, é elevar os itens na posição 3 para a posição 1. Ignorar a importância da arquitetura em detrimento de recursos não importantes pode levar um sistema a falência no longo prazo.
Lute pela arquitetura
Como dev, você precisa defender o que acredita ser melhor para a empresa. Como desenvolvedor, você é um stakeholder do software que precisa proteger. Então, nada mais certo que querer que este software viva muito bem.
Se você for um arquiteto, saiba que seu papel é mais importante ainda neste aspecto. Você foi contratado para dar estrutura aos sistemas, não funcionalidades. Essa estrutura deve permitir que as funcionalidades sejam facilmente desenvolvidas, modificadas e ampliadas. Se a arquitetura vier por último, o sistema ficará cada vez mais caro para desenvolver.
