Software: o senhor o escreve como um livro, o cultiva como uma planta, o acresce como uma pérola ou o constrói como um edifício? Como observa Steve McConnell em Code Complete 2, não há falta de metáforas de desenvolvimento de software:
Uma abundância confusa de metáforas cresceu em torno do desenvolvimento de software. David Gries diz escrever software é uma ciência (1981). Donald Knuth diz é uma arte (1998). Watts Humphrey diz é um processo (1989). P. J. Plauger e Kent Beck dizem que é como dirigir um carroembora tenham chegado a conclusões quase opostas (Plauger 1993, Beck 2000). Alistair Cockburn diz que é um jogo (2002). Eric Raymond diz que é como um bazar (2000). Andy Hunt e Dave Thomas dizem que é como jardinagem. Paul Heckel diz que é como filmar Branca de Neve e os Sete Anões (1994). Fred Brooks diz que é como cultivar, caçar lobisomens ou se afogar com dinossauros em um poço de piche (1995). Quais são as melhores metáforas?
Acho que estamos deixando na mesa uma metáfora que reflete com mais precisão a maneira como o software é criado no mundo real: andar por aí aleatoriamente e rezar para que o senhor seja bem-sucedido por força de pura sorte. Às vezes, isso até funciona. Não com muita frequência, mas apenas o suficiente para confundir as pessoas que deveriam saber mais e fazê-las pensar que são inteligentes, quando o que elas realmente são é sortudas.
A resposta, é claro, é qualquer metáfora que ajude o senhor e sua equipe a chegar ao final do projeto. Pessoalmente, eu as vejo mais como um grito de guerra, uma maneira de a equipe comunicar uma visão compartilhada e um conjunto de valores. Eles são pesados em imagens e metáforas e leves em conselhos específicos e concretos.
Mesmo quando Steve McConnell argumenta que a maioria das metáforas de desenvolvimento de software não funciona, ele claramente escolhe uma favorita e passa um bom tempo defendendo sua escolha. Isso não é exatamente um segredo, pois está no subtítulo do livro: Code Complete: A Practical Handbook of Software Construction (Manual prático de construção de software).
Por mais que eu respeite Steve, minha experiência em projetos de software até o momento não combina com a metáfora da construção controlada. Concordo com Thomas Guest; o software é flexível; os edifícios não são. Sou mais favorável ao modelo que Andy Hunt e Dave Thomas promovem, o que chamo de cuidando de seu jardim de software.
Programadores como fazendeiros, se o senhor preferir.
Todos os melhores projetos de software em que trabalhei eram, por falta de uma palavra melhor, vivos. Não quero dizer isso literalmente, é claro. Mas o software estava crescendo de forma constante e bastante visível. Havia cronogramas de lançamento regulares e frequentes que definiam sua evolução. Havia um compromisso de projeto de longo prazo para um ano, cinco anos, dez anos.
Para mim, os paralelos entre a agricultura e o desenvolvimento de software são fortes e sugestivos. Steve discorda.
O ponto fraco da metáfora da criação de software é a sugestão de que o senhor não tem nenhum controle direto sobre como o software se desenvolve. O senhor planta as sementes do código na primavera, Almanaque do Fazendeiro e a Great Pumpkin (Grande Abóbora), o senhor terá uma safra abundante de códigos no outono.
Para deixar claro, todas essas metáforas são abstratas e, portanto, muito sujeitas a interpretação (e/ou inúteis, o senhor escolhe), portanto, não quero me envolver demais na defesa de uma delas.
Dito isso, discordo da rejeição de Steve. O ponto forte da metáfora da agricultura é o fato de o compromisso com o ofício. A agricultura é um trabalho árduo e implacável, mas tem um ritual anual e sazonal, uma profunda apreciação subjacente do crescimento sustentável e controlado, que acredito que os desenvolvedores de software fariam bem em imitar. Também acho que Steve foi um pouco injusto ao caracterizar a agricultura como “sem controle direto”. Há muito controle, mas também muitas variáveis reconhecidas, o que, na minha opinião, representa com mais precisão o mudanças nas areias do desenvolvimento de software. Os agricultores fazem o melhor que podem para controlar essas variáveis, é claro, mas, acima de tudo, precisam se adaptar às condições que enfrentam. Na próxima temporada, no próximo ano, eles sabem que estarão de volta com um senso de propósito renovado para tentar tudo de novo e fazer melhor. Não por coincidência, essas também são características compartilhadas pelos melhores desenvolvedores de software que já conheci.
Em particular, o surgimento do modelo de desenvolvimento de software da Web tornou o modelo agrícola mais relevante. Enquanto o software tradicional, como o Office, pode passar por um monte de atualizações monolíticas e gigantescas de projetos de construção a cada dois ou três anos, do Office XP ao Office 2003 e ao Office 2007, os sites podem ser implantados com muito mais frequência. Sazonalmente, se o senhor preferir. Alguns sites até “colhem” mensalmente, desenvolvendo organicamente novos recursos e correções de bugs a cada vez. O pessoal da 37Signals aparentemente também notaram isso.
Recentemente, me dei conta de que o software cresce da mesma forma que as plantas. Os novos recursos são as flores do mundo do software. E, assim como a maioria das plantas não floresce o ano todo, o software não apresenta recursos o ano todo. Há uma estação de floração. Há a temporada de novos recursos. Há a temporada de infraestrutura.
Às vezes, o software está trabalhando em suas raízes. Reforçando sua infraestrutura. Ele está crescendo no subsolo, onde o público não pode ver. Parece que nada está acontecendo, mas na verdade há muita coisa acontecendo. Sem essas raízes, os novos recursos não podem brotar.
E, às vezes, é hora de descansar. As plantas descansam no inverno. O software geralmente descansa no verão (é muito bom trabalhar demais no verão). Tudo pode se beneficiar de uma respiração profunda, relaxamento e sono. O crescimento e a mudança caóticos e constantes não abrem espaço para a ordem e a organização. O crescimento requer nova energia e nova energia requer descanso.
Outra coisa que notei é que cuidar de sites, que geralmente têm recursos de comunidade e conteúdo gerado pelo usuário em primeiro plano, é muito parecido com capinar seu jardim. O senhor produz muito conteúdo, mas nem todo ele é exatamente o que tinha em mente.
Examino minuciosamente todos os comentários e removo uma pequena porcentagem deles: podem ser spam, claramente fora do assunto ou simplesmente maldosos. Gosto de me referir a isso como capinar meu jardim na Web. É uma taxa de produtividade que o senhor paga se quiser ter uma safra abundante de comentários, que.., apesar do que Joel diz, muitas vezes dão frutos maravilhosos. O trabalho pode ser minimizado com equipamentos aprimorados, mas ele sempre está presente de alguma forma. E não me importo com isso. Os inúmeros benefícios de um ecossistema de comentários robusto superam o pequeno esforço de manutenção.
E quando o senhor não capina seu jardim? As ervas daninhas ameaçam sufocar suas plantações. Eventualmente, seu jardim de software parece negligenciado e depois abandonado.
Como diz Steve, algumas metáforas de desenvolvimento de software são melhores do que outras. Mas, pelo menos no que se refere ao desenvolvimento da Web, o senhor certamente poderia fazer muito pior do que cuidar de seu jardim de software.