Em 1975, Frederick P. Brooks escreveu o revolucionário The Mythical Man-Month. Quarenta anos depois, esta série de artigos pretende revisar as afirmações e os argumentos do autor. Quanto o ofício da Engenharia de Software evoluiu desde então?
Capítulo 5: The Second-System Effect
Neste capítulo, Brooks trata sobre problemas em separar a arquitetura da construção, basicamente o que ele sugeriu no capítulo anterior.
Disciplinas de um arquiteto efetivo
Comunicação frequente e precoce pode dar ao arquiteto melhores aproximações do custo e mais confiança no projeto, sem ultrapassar a divisão de responsabilidades.
Primeiro ele sugere algumas disciplinas que o arquiteto precisa ter. Arquitetar livremente geralmente leva a projetos irreais, com custos proibitivos. O remédio seria comunicação frequente e o mais cedo possível com os desenvolvedores, de modo a colher feedback sobre o custo real da implementação.
No decorrer do projeto, o arquiteto precisa ouvir os desenvolvedores e frequentemente vai chegar à conclusão de que o custo vai ultrapassar o orçamento. Então ele tem duas opções, basicamente:
- Diminuir o escopo do projeto; ou
- Sugerir uma forma mais barata de implementação.
No segundo caso, ele está dizendo ao construtor como ele poderia fazer o seu trabalho de outra forma, então muito cuidado nessa hora, afinal sentimentos estão em jogo. Ele sempre deve estar preparado para ouvir contra-argumentos e ser humilde para aceitar que os desenvolvedores podem ter razão.
Então, Brooks fornece alguns princípios que todo que se diz arquiteto deveria fixar num quadro ou estampar numa camiseta:
- Lembre que o desenvolvedor tem a responsabilidade criativa pela implementação; o arquiteto apenas faz uma sugestão.
- Esteja sempre pronto para sugerir uma forma de implementação para qualquer coisa especificada; esteja também preparado para aceitar qualquer outra boa forma de fazer a mesma coisa.
- Lide de forma discreta e privativa quando der sugestões de implementação. Esteja pronto para deixar outras pessoas levarem o crédito por suas sugestões de melhorias.
- Ouça as sugestões de melhorias que o desenvolvedor der para a arquitetura.
O único ponto discutível aqui, em minha opinião, é a questão de lidar com sugestões de forma privada. Algumas vezes isto é necessário se houver pessoas sensíveis na equipe, mas é muito melhor criar uma cultura onde os desenvolvedores estão prontos a dar r ouvir críticas construtivas e sugestões. O ideal é ter bom senso e verificar o melhor em cada situação, além de ter tato de não agredir verbalmente ninguém, ainda que sutilmente, por causa de uma falha pontual, falta de conhecimento ou qualquer outra coisa.
Eu diria que o bom arquiteto é aquele que faz o projeto andar tecnicamente da melhor forma possível e, ao mesmo tempo, mantém os desenvolvedores tecnicamente motivados. Bem o contrário de quem quer usar a força do cargo ou da experiência para impor a própria opinião técnica.
Note que limitei a influência ao aspecto técnico, afinal estamos falando de arquitetura e não de gerenciamento ou liderança, mas o mesmo princípio de aplica a qualquer área.
O perigo do segundo sistema
O segundo sistema é o mais perigoso que uma pessoa jamais vai projetar; a tendência geral é exagerar no projeto.
Brooks afirma que o segundo sistema que um arquiteto projeta é o mais perigoso de todos.
Como diz o provérbio:
A soberba precede à ruína; e o orgulho, à queda. (Provérbios 16:18)
E o ditado:
O ótimo é inimigo do bom.
No seu primeiro trabalho o arquiteto é cuidadoso. Ele está um pouco inseguro, logo planeja tudo com parcimônia.
Na segunda versão ele já está muito mais confiante e resolve colocar em prática todas as grandes ideias que ele teve antes, mas que evitou incluir antes.
Já ouviu falar de overengineering?
Muitas vezes reclamamos de pouco tempo para desenvolver projetos. Mas a prática mostra que projetos com muito tempo e dinheiro também são um problema. Os desenvolvedores acabam com algo monstruosamente complexo ou demasiadamente refinado, mas com pouca relevância prática.
Outro problema é investir demais em algo praticamente obsoleto. Um exemplo moderno seria desenvolver um novo sistema de geração de boletos bancários melhor e mais refinado que todos os existentes. Só que esse modelo de pagamento está sendo cada dia mais em desuso além de não haver motivação prática que leve à migração para o novo sistema só porque ele é mais bem-feito tecnicamente.
A solução de Brooks para o perigo do segundo sistema é ter um arquiteto mais experiente para orientar o projeto, isto é, que já participou de dois projetos ou mais e está vacinado contra as armadilhas da autoconfiança exagerada.
Considerações
Este capítulo contém conselhos muito importantes. Eles não são de cunho técnico, mas extremamente valiosos.
Eu não diria, porém, que o efeito do segundo sistema é algo específico para os arquitetos e nem limitado ao segundo sistema. Líderes e gerentes em geral, desenvolvedores que fazem projetos sem supervisão e várias outras categorias podem cair facilmente na armadilha de refinar demais um sistema ou simplesmente investir demais em algo que não vai trazer um retorno proporcional.
Porém, fazer bom uso da sabedoria dos antigos não é obedecer a um conjunto de regras cegamente, sem compreensão, mas passa por um processo de auto-conhecimento e interiorização dos princípios.
Quando digo isso, tenho em mente certos desenvolvedores que, neste ponto do artigo, estão se sentindo desculpados por fazerem um trabalho fraco ou mediano e não se esforçam pelo melhor.
Se existe alguma coisa que você precisa entender é que você deve olhar sempre para o ótimo, mas ser realista e almejar o bom que é possível. Em outras palavras, seja realista e não preguiçoso.
Fazer o possível, o bom, não é o mesmo que ser desleixado ou fazer menos do que o seu melhor. De toda a minha experiência, a regra é que o nosso melhor dá um resultado bom e menos do que isso é ruim, geralmente muito ruim. Programadores são otimistas demais e eles sempre acaba fazendo menos, às vezes muito menos, do que se pensava a princípio.
