Alguém–não me lembro quem no momento–me recomendou o livro Software Craftsmanship, de Pete McBreen, como um bom tratamento do tema de software como engenharia versus software como ofício (craft é uma palavra notoriamente difícil de traduzir; artesanato poderia também ser usado).
O tema é excelente, mas eu fiquei estupefato com quão ruim o livro é. Não pelo modo como McBreen trata o tema em si–na verdade, ele consegue até produzir alguns insights interessantes–mas pela repetição exaustiva das mesmas frases e argumentos.
Eu não sei que editor deixou isso passar, mas se a repetição incessante de argumentos idênticos fosse removida, o livro provavelmente cairia de suas quase trezentas páginas para pouco mais do que cinqüenta. O que me tomaria talvez seis ou oito horas de leitura–com anotações incluídas–me tomou mais que o dobro disso enquanto eu tentava remover a verbosidade de McBreen na maioria dos capítulos do livro.
A idéia de McBreen é simples: engenharia de software é algo apropriado para projetos enormes (mais de 100 anos/desenvolvedor) enquanto que para projetos menores, com necessidades mais rápidas de time-to-market, o velho modo de ofício medieval é mais apropriado: um mestre-artesão, com vários artesãos sob ele, e vários aprendizes sob estes outros.
Eu concordo com o argumento e concordo com muitas das conclusões a que McBreen chega. De fato, no que tange à minha própria empresa, este é virtualmente o modo que operamos, usando uma hierarquia de experiência na maioria dos projetos. Os resultados tem sido excelentes.
O problema de McBreen é que, ao descrever as raízes e razões do argumento, além das repetições citadas acima, ele sai com várias declarações do tipo:
Software craftsmanship is the new imperative because many members of the software development community are stating to chase technology for its own sake, forgetting what is important.
O fato de que a segunda parte desta frase é extremamente óbvia e que a relação entre as duas partes da mesma é um non-sequitur não parece incomodar o autor.
Apesar disso, muito do que McBreen fala é válido e importante, como ao descrever como software que é bom o bastante é ruim para usuários e para a indústria como um todo e como soluções diferentes podem tratar isso de uma maneira mais interessante. Algumas de suas análises sobre as metáforas que permeiam a indústria–como a da construção de um carro versus o projeto de um carro–são bem apropriadas e são parte do que me motivou a terminar o livro apesar da dificuldade com o mesmo.
Em última instância, o livro trata de um tema bem necessário e faz parte de algo que é hoje está se tornando um dos debates mais importantes da nova onda de desenvolvimento. Eu temo, porém, que muitos leitores abandonarão a sua leitura depois de menos que um terço do livro ao perceber a redundância do estilo de McBreen. Com um editor bom, o livro teria de transformado em um Peopleware de sua geração. Infelizmente esse não foi o caso.
1 dos Pricipios da maioria das Abordagens Ágeis é barely good enough. Isto não é um contra-ponto quando McBreen afirma “[...]software que é bom o bastante é ruim para usuários e para a indústria como um todo[...]“??!
O q vc quis dizer: uma parte da frase de McBreen é um non-sequitur da outra???!
[...] termo foi criado com a publicação do livro de Pete McBreen em 2002. Fala-se sobre aprender com mestres. Aprenda as habilidades e como tomar decisões, mas [...]
[...] termo foi criado com a publicação do livro de Pete McBreen em 2002. Fala-se sobre aprender com mestres. Aprenda as habilidades e como tomar decisões, mas [...]