The Mythical Man-Month


Pode parecer estranho mas acabei de ler um livro sobre tecnologia, melhor sobre desenvolvimento de software, que foi escrito há 33 anos.
Para além da eventual afinidade que poderia ter por ler um livro que tem exactamente a minha idade, a verdade é que o que me levou a ler o ‘The Mythical Man-Month’ foi o reconhecimento que muitas pessoas ainda hoje revelam sobre o livro.
‘The Mythical Man-Month’ é um conjunto de artigos escritos como resultado do desenvolvimento do sistema OS/360 e do reconhecimento do que correu menos bem ou mesmo mal e tentativa de explicação desses erros.
E a verdade é que, com muita pena minha, consegui rever uma grande parte da minha vida profissional aí reflectida… é triste saber que estou a repetir erros que foram identificados há 33 anos…

Mas este livro serve-me também de enquadramento mental a alguns aspectos da minha profissão. Seja numa perspectiva histórica, onde podemos ver alguns fundamentos de metodologias modernas como extremme programming, seja na vertente da comunicação do projecto ou, na prática do pair-programming

“Notice in particular the differences between a team of two programmers conventionaly organized and the surgeon-copilot team. First, in the conventional team the partners divide the work, and each is responsible for design and implementation of part of the work. In the surgical team, the surgeon and copilot are each cognizant of all the design and all of the code.”

seja na definição do âmbito da nossa profissão, da matéria com a qual trabalhamos e do que nos leva a gosta de trabalhar nela.

“capitulo 2 – The Mythical Man Month pag. 15
The programmer builds from pure thought-stuff: concepts and very flexible representation thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified.”

É dificil sintetizar todo o livro numa palavra, mas sendo um livro mais ou menos de gestão de projectos, é também um livro de gestão de relações humanas e de constatação que o desenvolvimento de software mais do que um fim (o produto final) é um processo – “grow, not build, software”.
Apesar de estarmos cada vez mais acima nas camadas de abstracção que nos levam do hardware (porque todo o software ainda corre num hardware) até ao domínio de negócio que queremos “softwarizar” continua a ser verdade que:

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other sofware systems. No other part of the work so cripples the resulting system if done wrong. No other part is so more difficult to rectify later.
Therefore the most important function that software builders do for their clients is ther iteractive extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they almost never have thought of the problem in the detail that must be specified. Even the simple answer – “Make the new software system work like our old manual information-processing system” – is in fact too simple. Clients never want exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteraction between the client and the designer as part of the system definition.
I would go a step further and assert that it is really impossible for clients, event those working with software engineers, to specifiy completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.”

Torna-se por isso para mim cada vez mais claro que um projecto de desenvolvimento de software é um projecto onde não se consegue especificar concretamente o que vai ser feito e logo quanto tempo vai demorar a fazer e portanto quanto é que deve custar.

“The programmer delivers satisfaction of a user need rather than any tangible product” (pag.241)

E com uma definição tão abstracta para algo que no fim vai ser muito concreto (n linhas de código) percebemos que um projecto que tem que assentar na confiança entre todos os participantes do projecto.
Note-se no entanto que esta confiança não tem a ver com a ideia de fé ou crença mas sim de confiança porque todos os dados disponiveis apontam para que as soluções optadas são as mais apropriadas. Certamente que haverá erros durante o processo mas estando todos os envolvidos no projecto a par das decisões e dos objectivos, esses erros não terão mais relevância do que a necessária para evitar que se repitam.

Para além da ideia de desenvolvimento incremental e da ideia clara que “the clients do not know what they want”, outro ponto importante que é referido tem a ver com o papel do gestor de projecto e a sua relação com as pessoas que está a coordenar.
Como acontece provavelmente em relação a todas as profissões, também no desenvolvimento de software, a definição de prazos e datas é uma espécie de luta entre quem define o tempo que as tarefas demoram (programador) e quem quer gerir os deadlines (gestor de projecto) como se o facto de se querer algo mais rápido fosse sinónimo de ser possivel ter algo mais rápido…

“The project manager has to keep his fingers off the estimated dates, and put the emphasis on getting accurate, unbiased estimates rather than palatable optimistic estimates of self-protective conservative ones.”

Ou seja, em vez de números e datas à partida irrealistas mas com potencial “psicológico” para o nivel hierarquicamente superior e/ou clientes, é preferivel batalhar para ter datas fiáveis e por isso cada vez mais confiáveis.

Todos estes pontos parecem às vezes banalidades e/ou generalidades com que todos podemos concordar, mas como disse no inicio não é pelo facto de eu os conhecer que não sofri até agora na pele o efeito de cada um desses pontos…


outros artigos relacionados:


Nome: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
Autor: Frederick P. Brooks
Editora: Addison-Wesley Professional; 2 edition (August 12, 1995)
ISBN-13: 978-0201835953

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *