Em minha palestra "Scaling Lean & Agile: Large, Multisite or Offshore Delivery", na QCon Londres 2011, mencionei que arquitetura não é uma boa metáfora e que não construímos software como um edifício; nós o cultivamos como um jardim. Isto deu origem a muitos tweets, e vários mostraram interesse em conhecer mais detalhes sobre a ideia.
(Disponibilizamos um PDF gratuito (em inglês) do capítulo "Projeto e Arquitetura" do nosso livro para acompanhar o presente artigo.)
A primeira coisa que gostaria de destacar é que a metáfora do jardim e o argumento em geral são muito antigos. Comecei a trabalhar com desenvolvimento nos anos 70 (como programador da linguagem APL). Nessa época, Harlan Mills era um "guru" importante e muitos programadores, inclusive eu, eram influenciados pelos seus textos, que enfatizavam a programação de cima para baixo (top-down). Um exemplo é o artigo "Programação Top-Down em Grandes Sistemas" [Mills 1971], no qual Mills falava sobre como evoluir sistemas ampliando incrementalmente recortes verticais de funcionalidades, sendo o programa refinado passo a passo. Foi dessa maneira que aprendi a projetar e desenvolver grandes sistemas de software (inicialmente no setor de seguros).
Então, em 1986 Fred Brooks publicou seu famoso artigo "Não Existe Bala de Prata – Essência e Acidente em Engenharia de Software" [Brooks 1986] . E assim como aconteceu com muitos outros programadores na década de 80, o artigo teve grande impacto sobre meu trabalho. Alguns trechos deste artigo, tratando da metáfora do cultivo/jardinagem, são dignos de nota:
A metáfora do edifício [aplicada ao desenvolvimento de software] já perdeu sua utilidade; é hora de mudar novamente. As estruturas conceituais que hoje construímos são complexas demais para serem especificadas detalhadamente com antecedência; são também complexas demais para serem construídas sem defeitos. Devemos, portanto, adotar uma abordagem radicalmente diferente. Vamos nos voltar à natureza e estudar a complexidade das coisas vivas, em vez dos trabalhos mortos do homem.
Nesse contexto, encontramos estruturas com uma complexidade imensa: o cérebro, por exemplo, é mais complexo do que é possível mapear e mais poderoso do que se pode imitar; é rico em diversidade, autoprotetor e auto-renovador. O segredo é que o cérebro evolui; não é construído. O mesmo deve acontecer com nossos sistemas de software; alguns anos atrás, Harlan Mills propôs que qualquer sistema de software deve ser evoluído através do desenvolvimento incremental.
Cresci, portanto, com a metáfora de cultivar sistemas em vez de construí-los. Ainda lembro meu sentimento de dissonância cognitiva quando ouvi pela primeira vez o termo "arquiteto" no contexto do desenvolvimento de software, nos meados da década de 80. O nome e a metáfora soaram estranhos e inconsistentes com minha experiência e a de meus colegas em desenvolver sistemas. Nos anos 70, estávamos familiarizados com a disfunção representada por essa classe de "arquitetos", hoje chamados "arquitetos de PowerPoint", que estavam muito longe da realidade do código.
Dessa forma, ao afirmarmos numa palestra de 2011 que arquitetura não é uma boa metáfora e que não construímos software como um edifício, estamos compartilhando o ponto de vista que tínhamos e ainda temos. A intenção, certamente, não era sugerir uma nova ideia brilhante ou de ponta sobre o projeto ágil de software.
E esta é uma mensagem muito divulgada; no seu livro The Pragmatic Programmer [HT 1999], por exemplo, Andy Hunt e Dave Thomas repetem que "em vez de construção, a programação é mais parecida com jardinagem." Estão reforçando mais uma vez a dinâmica viva e evolutiva do desenvolvimento de software, o que é muito diferente das metáforas de engenharia que têm confundido nossa disciplina. Mas você pode estar se perguntando: "E daí? É só uma metáfora!". (A propósito, "jardinagem" também se trata de uma metáfora e também tem seus pontos fortes e fracos.)
Este é um momento muito interessante para escrever este artigo, porque há poucos dias recebi um email em que me perguntavam como fazer a contabilidade e alocação de custos no desenvolvimento iterativo e incremental com engenharia concorrente (por exemplo, em Scrum). O que poderia ser alocado em despesas operacionais e o que ficaria em despesas de capital (que tem depreciação e impostos diferentes)?
Uma palavra como "arquitetura" não é apenas uma metáfora, devido ao seu impacto. Ela tem influência concreta nas políticas e sobre as pessoas. Voltando ao caso dos custos, fica claro que os contadores olharam para as "fases" e atividades do desenvolvimento com sua visão leiga, para responder seus questionamentos sobre contabilidade baseada em atividades. Esses contadores aprenderam (leram, ouviram) que existe uma "fase de arquitetura" executada por "arquitetos", seguida por uma de "construção" chamada de "programação". Assim como num edifício real, concluíram por analogia, inspirados pelo que ouviram (já que na realidade não sabem o que está acontecendo), que a etapa criativa do projeto é feita pelos "arquitetos" (com suas respectivas despesas operacionais), e a "fase de programação" é uma atividade não-criativa, de manufatura, tal como fazer pastéis numa linha de produção, com base no "modelo arquitetural do software". E isto é despesa de capital.
Obviamente, tal coisa não faz o menor sentido, como sabe qualquer desenvolvedor de software experiente.
Mas o fato é que as palavras podem influenciar enormemente a formação de modelos mentais e consequentemente as políticas e os comportamentos. Alguém que não seja da área de software mas tenha poder político (por exemplo, um CEO, um gerente de RH etc.) ouve a palavra "arquitetura" e faz suposições ingênuas que têm impacto sobre a política, processo, interações, carreiras, e mais. Com tudo isso, "arquitetura" deixa de ser apenas uma metáfora.
Por isso, no nosso último livro [LV 2010], Bas Vodde e eu escrevemos o capítulo já citado (e disponível para download), "Projeto e Arquitetura". O texto começa com a sugestão: Tente pensar em "cultivar" em vez de "arquitetar"; crie uma cultura de projeto vivo e evolutivo". E nós elaboramos essa ideia em sete páginas com muito mais detalhe. Também aprsentamos cerca de vinte outras sugestões de formas de trabalhar para apoiar o projeto e a arquitetura ágeis em grande escala. Acreditamos que a arquitetura ágil vem do comportamento de arquitetar de maneira ágil. É acima de tudo mentalidade e ações; não se trata do uso de algum padrão de projeto específico. Além do capítulo do nosso livro, há várias outros bons textos sobre "jardinagem de software", como os livros e artigos online dos "programadores pragmáticos" Andy Hunt e Dave Thomas.
Referências
- [Brooks 1986] Brooks, Jr., F.P., "No Silver Bullet—Essence and Accidents of Software Engineering," Information Processing 86. H.J. Kugler, ed. Elsevier Science Publishers B.V. (North Holland)
- [HT 1999] Hund, A., Thomas, D. The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley.
- [LV 2010] Larman, C., Vodde, B. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison- Wesley.
- [Mills 1971] H.D. Mills, "Top-Down Programming in Large Systems," in Debugging Techniques in Large Systems, R. Ruskin, ed., Prentice-Hall.
Sobre os Autores
Craig Larman é consultor na área de implantação de princípios ágeis e Scrum em ambientes corporativos. É autor do livro Agile & Iterative Development: A Manager's Guide, e coautor (juntamente com Bas Vodde) do livro Scaling Lean & Agile Development: Thinking & Organizational Tools e Practices for Scaling Lean & Agile Development: Large, Multisite, & Offshore Product Development with Large-Scale Scrum. Atuou como coach na Alcatel-Lucent Networks, Xerox, Nokia Siemens Networks, Computer Associates e UBS, entre outras. Além disso, implantou a metodologia de entregas ágeis no setor de defesa, nos EUA. Foi cientista-chefe na Valtech, uma empresa de consultoria e desenvolvimento com filial em Bangalore, onde ele e seus colegas criaram o "desenvolvimento ágil offshore"."
Bas Vodde é consultor e coach, com foco na implantação técnica e organizacional de conceitos ágeis. Em parceria com Craig Larman, escreveu os livros Scaling Lean & Agile Development: Thinking & Organizational Tools e Practices for Scaling Lean & Agile Development: Large, Multisite, & Offshore Product Development with Large-Scale Scrum. Por muitos anos liderou a implantação de metodologias ágeis na Nokia Siemens Networks. Atualmente trabalha em sua própria empresa de consultoria em práticas ágeis, fundada em Cingapura e com escritórios na China e noJapão.
A dupla de autores também escreveu o livro gratuito Lean Primer.