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.
De forma geral, eu concordo.
Contudo, normalmente quem está acima dos devs não busca entender e prezar por uma boa arquitetura. Não são todos os desenvolvedores que conseguem negociar com esses gerentes. Ao meu ver, um gerente/supervisor deve salientar a necessidade de uma boa estrutura/arquitetura desde o princípio. Que não seja ele, que seja o tech lead. Mas o time de desenvolvimento precisa sentir que há espaço para defender uma arquitetura sem viver com medo de ser demitido por defender seus ideais (não falo sobre teimosia, mas sim buscar um consenso).
Top comments (1)