Inóspito

Faço desenvolvimento de software há quase 10 anos. Por esta altura deveria ser gestor de projecto ou arquitecto de software. Na grande maioria das empresas este é o caminho natural de evolução: começa-se como programador, depois programador sénior e depois, se formos empenhados, em 5 anos passamos a gestores de projecto (para onde é que evoluímos nos 30 anos seguinte é um mistério que não parece preocupar ninguém!).

95% dos meus colegas de curso são agora gestores de projecto. Ao que sei passam muito tempo em reuniões e em frente ao outlook. Muitos deles parecem estar satisfeitos com essa posição, porque já estavam saturados de programar ou (e estes poderão ser os melhores gestores) porque nunca gostaram de programar. Talvez alguns estejam satisfeitos porque os benefícios financeiros são muito interessantes (muito mais interessantes do que se ainda estivessem a programar).

Sobram portanto 5%, que se dividem em dois: aqueles que resolveram criar a sua própria empresa e os arquitectos de software. Em relação aos primeiros, queria desejar-lhes muito boa sorte. Respeito-os tremendamente e gostava sinceramente que fossem uma percentagem maior porque são um dos motores de inovação que Portugal desesperadamente precisa. Em relação aos arquitectos de software, gostava de começar pela definição que aparece na Wikipedia, em que esta figura se prende com a complexidade crescente do software nos últimos anos:

The software architect concept began to take hold when object oriented programming (OOP) was coming into more widespread use (in the late 1990s and early years of the 21st Century). OOP allowed ever-larger and more complex applications to be built, which in turn required increased high-level application and system oversight.

De seguida, descreve as suas principais responsabilidades que incluem a definição de metodologias de desenvolvimento e o desenho ou escolha de frameworks sobre as quais assentará o desenvolvimento de uma certa aplicação. Não tenho dúvidas que isto são tarefas essenciais no desenvolvimento de software de qualidade. Mas porque razão tem que ser um arquitecto a fazê-las? Eu faço estas tarefas practicamente desde o início da minha carreira. Tinha eu 6 meses de experiência e já estava a propôr um standard para formatação do código à equipa na qual trabalhava. Sim, eu sei, é uma ideia ridícula mas dêem-me um desconto – eu era um novato! A questão aqui é: não é suposto todos os programadores serem arquitectos de software, na medida em que devem utilizar e melhorar metodologias e ferramentas para atingir os seus objectivos? Ou é suposto haver esta distinção elitista entre os ominiscientes arquitectos astronautas e os vulgares code monkeys?

Não percebo muito de construção civil mas suponho que faça sentido alguém ser arquitecto sem nunca ter montado uma parede de tijolos. O problema é que programar não tem nada a ver com montar tijolos. Só na cabeça de algumas gestores dilbertianos é que isso faz sentido. É que os tijolos do software não são rectangulares, assumem as formas mais bizarras e conseguir juntá-los sem que o resultado pareça um quadro surrealista não é, claramente, uma tarefa previsível ou repetitiva. Além disso, a Engenharia Civil tem centenas de anos de evolução enquanto a Engenharia Informática tem umas décadas. Isto nem se devia chamar Engenharia, pois esta pressupõe que utilizando princípios matemáticos podemos prever o comportamento de um “engenho”. A haver arquitectos certamente incluiriam nomes como Martin Fowler, Kent Beck, Joshua Bloch ou Linus Torvalds. Tanto quanto sei nenhum se intitula arquitecto. Todos eles continuam a programar e a ajudar outros a programar. O próprio Martin Fowler escreveu um artigo “Who Needs an Architect?”, no qual prefere o termo “guia” a “arquitecto”:

(…) came up with the best name I’ve heard so far: guide, as in mountaineering. A guide is a more experienced and skillful team member who teaches other team members to better fend for themselves yet is always there for the really tricky stuff.

Note-se, eu acredito na arquitectura de software. Pensar como vamos ligar os componentes de uma aplicação é uma das tarefas mais interessantes no desenvolvimento de software. Mas é algo que tem que ser feito durante a implementação. Pensa-se, experimenta-se, adapta-se, re-experimenta-se, discute-se, re-experimenta-se, refactoriza-se, re-experimenta-se, num ciclo constante de desenvolvimento.

Precisamos então de arquitectos de software?

Sim, mas os arquitectos são também os programadores. Todos. Acabemos com essa distinção ridícula que só existe para justificar progressões na carreira de quem não quer ser gestor de projecto. Ouvi isto muitos anos e continuo a ouvir: “quem quer seguir uma carreira técnica evolui para arquitecto de software”. A teoria é que as empresas não querem pagar salários elevados a quem só programa porque fica demasiado caro. Então criam esta figura de arquitecto, que aparece no início dos projectos, qual Chuck Norris dos computadores, define uma arquitectura fantástica em 3 dias e segue para outro projecto porque este já ficou “bem encaminhado”. As mesmas empresas esquecem-se que programar é aquilo que elas fazem por excelência. Elas são pagas para produzir software que resolva os problemas de alguém disposto a pagar. Tudo o resto: arquitectura, documentação, gestão de projecto, planos de qualidade, etc., são artefactos que giram à volta da programação para complementar o produto final. A tarefa nobre devia ser a programação, não aquilo que anda à volta dela. Citando um artigo da devx:

Deliver code that does what the end users of the code need or want. No more, no less. From Web sites to database applications to games, it’s all about what your code will do for the end user and not about how you did it. Your end users don’t care if you used a Booch diagram or anointed blocks with arrows and written descriptions to communicate to the development team how you were going to build the software. They care only that the software works the way they expect it to.

Ok, agora que enfureci todos os arquitectos de software que possam vir a ler este blog, sinto-me obrigado a admitir que, embora todos os programadores sejam também arquitectos, alguns são melhores arquitectos do que outros, e por isso é normal e desejável que exista um elemento com mais experiência e mais jeito para estas coisas que tenha um papel mais importante no arranque do projecto. A meu ver, esse papel pode-se materializar da seguinte forma, depois de toda a equipa ter acordado numa arquitectura:

• Programar o primeiro componente da aplicação, porque esse servirá de exemplo para todos os seguintes. Além disso, desenvolver o primeiro componente demora muito mais que desenvolver os seguintes, por isso é vantajoso ser desenvolvido por alguém com uma produtividade elevada.
• Escolher o componente com maior número de dependências e implementá-lo, para que seja obrigado a interagir com o máximo de componentes desenvolvidos pela equipa e assim detectar facilmente falhas na arquitectura inicial ou problemas de implementação nos restantes componentes.

Pode parecer uma abordagem pouco científica mas tem funcionado muito bem comigo, espero que ajude outros (arquitectos ou não).