Prefácio da edição de 20o aniversário

Para minha surpresa e satisfação, ao cabo de 20 anos, o Mítico Homem-

Mês continua sendo popular, com mais de 250 mil cópias impres-
sas. Não raro as pessoas me perguntam quais opiniões e recomendações ainda
conservo desde 1975, e o que mudou de lá para cá e como se deu essa mudança.
Mesmo que eu tenha, de tempos em tempos, respondido a essas perguntas em
minhas aulas, há muito eu queria apresentá-las em um ensaio.
Peter Gordon, hoje editor e sócio da Addison-Wesley, trabalha comigo desde
1980 com paciência e dedicação. Ele propôs que preparássemos uma Edição de
Aniversário. Decidimos não revisar o original, publicando-o sem retoques (à exce-
ção das correções habituais) e ampliando-o com pensamentos mais atualizados.
O Capítulo 16 traz novamente “Não existe bala de prata: essência e acidente
em engenharia de software”, um artigo apresentado no IFIPS* de 1986, redigido
com base em minha experiência de chefe de um estudo do Comitê Científico de
Defesa sobre software militar. Meus coautores nessa pesquisa e também Robert
L. Patrick, nosso secretário executivo, foram inestimáveis ao colocarem-me no-
vamente em contato com grandes projetos de software do mundo real. O artigo

* International Federation of Information Processing Societies.

O mitico homem-mes - cad 0.indd vii 17/06/2009 09:56:47

 viii O mítico homem-mês

foi reimpresso em 1987 na IEEE Computer Magazine, o que resultou em sua

ampla circulação.
“Não existe bala de prata” causou polêmica. O artigo predizia que uma déca-
da se passaria sem que fosse vista uma técnica de programação que traria, por si,
o crescimento de uma ordem de grandeza na produtividade de software. Ainda
falta um ano para esta década terminar e minha previsão está segura. “Não existe
bala de prata” estimulou muitas e muitas discussões espirituosas, mais do que as
inspiradas pelo O Mítico Homem-Mês. Por isso, o Capítulo 17 tece comentários
sobre algumas das críticas publicadas e atualiza as opiniões expressas em 1986.
Ao preparar minha retrospectiva e atualização de O Mítico Homem-Mês, cho-
cou-me o fato de que poucas das proposições nele expostas têm sido criticadas,
provadas ou derrubadas pela pesquisa e experiência em engenharia de software.
Para mim, foi comprovadamente útil catalogar, agora, essas proposições em sua
forma crua, livres de argumentos e dados que as suportem. Na esperança de que
essas declarações cruas atraiam argumentos e fatos que as comprovem, refutem,
atualizem ou refinem, incluí um esboço no Capítulo 18.
O Capítulo 19 é o próprio ensaio atualizado. O leitor deve estar ciente de
que as novas opiniões não são sequer aproximadamente tão bem embasadas pela
experiência das trincheiras, como foi o caso do primeiro livro. Tenho trabalhado
na área acadêmica e não na área industrial, em projetos de pequena escala, em vez
de grandes. Desde 1986, venho ensinando apenas engenharia de software, sem
fazer nenhuma pesquisa sobre o assunto. Minha pesquisa tem sido em ambientes
virtuais e suas aplicações.
No preparo deste retrospecto, busquei a visão atual de amigos que trabalham
de fato com engenharia de software. Pela fantástica vontade de compartilhar as
visões, de comentar profundamente os rascunhos e de reeducar-me, fico em dívi-
da com Barry Boehm, Ken Brooks, Dick Case, James Coggins, Tom DeMarco,
Jim McCarthy, David Parnas, Earl Wheeler e Edward Yourdon. Fay Ward tratou
explendidamente da produção técnica dos novos capítulos.
Agradeço a Gordon Bell, Bruce Buchanan, Rick Hayes-Roth, meus colegas
na Força-Tarefa de Software Militar no Comitê Científico de Defesa e, sobretu-
do, a David Parnas por suas sacadas e ideias estimulantes e Rebekah Bierly pela
produção técnica do artigo apresentado aqui na forma do Capítulo 16. A análise
de um problema de software nas categorias de essência e acidente foi inspirada
por Nancy Greenwood Brooks, que fez esse tipo de análise em um artigo sobre a
pedagogia do método Suzuki para o ensino de violino.

O mitico homem-mes - cad 0.indd viii 15/06/2009 17:57:57

 Prefácio da edição de 20o aniversário ix

A casa Addison-Wesley não permitiu que eu reconhecesse no prefácio da

edição de 1975 os papéis-chave exercidos por sua equipe. Por sua contribuição,
duas pessoas merecem destaque especial: Norman Stanton, na época editor-exe-
cutivo e Herbert Boes, então editor de arte. Boes desenvolveu o estilo elegante
que um crítico especialmente citou: “margens amplas e o uso imaginativo de
fonte e leiaute”. Mais importante, ele também fez a recomendação crucial para
que cada capítulo contasse com uma imagem de abertura. (Eu tinha apenas o
Poço de Alcatrão e a Catedral de Reims naquele tempo.) Encontrar as gravuras
ocasionou um ano a mais de trabalho para mim, mas sou eternamente grato pelo
conselho.
Soli Deo gloria – Para Deus apenas a glória.

F. P. B. Jr.
Chapel Hill, N. C.
Março de 1995

O mitico homem-mes - cad 0.indd ix 15/06/2009 17:57:58

 Prefácio da primeira edição

De diversas maneiras, gerenciar um grande projeto de pro-

gramação de computadores é o mesmo que ge-
renciar qualquer outro grande empreendimento – muito além do que a maioria
dos programadores acredita. Mas, sob outros aspectos, é diferente – muito além
do que a maioria dos gerentes profissionais espera.
Nesse campo, o saber é cumulativo. Muitos eventos, sessões nas conferências
AFIPS*e alguns livros e artigos existem há certo tempo. Mas, de forma alguma,
essa abundância de informações recebeu o tratamento sistemático de um livro-
texto. Parece oportuno oferecer este pequeno livro que reflete, essencialmente,
uma visão pessoal.
Mesmo que minha formação tenha sido no âmbito da programação em ci-
ência da computação, estive envolvido sobretudo com a arquitetura de hardware
nos anos (1956-1963) em que se desenvolveram programas de controle autôno-
mos e compiladores para linguagens de alto nível. Quando, em 1964, tornei-me
gerente do Sistema Operacional /360 (OS/360), encontrei um mundo de pro-
gramação um tanto mudado pelo progresso dos poucos anos precedentes.
Gerenciar o desenvolvimento do OS/360 foi uma experiência bastante edu-
cativa, embora muito frustrante. A equipe, incluindo F. M. Trapnell, que foi

* American Federation of Information Processing Societies.

O mitico homem-mes - cad 0.indd xi 15/06/2009 17:57:59

 xii O mítico homem-mês

meu sucessor como gerente, tem muito do que se orgulhar. O sistema contém
aspectos excelentes, tanto de projeto quanto de execução, e foi um sucesso, che-
gando à utilização em larga escala. Algumas ideias, mais notavelmente o sistema
de entrada e saída (input-output), independente dos dispositivos utilizados, e um
gerenciamento de bibliotecas externas constituíram inovações técnicas que hoje
são amplamente copiadas. O sistema é, agora, bastante confiável, razoavelmente
eficiente e muito versátil.
Esse esforço não põde ser considerado, entretanto, um sucesso completo.
Qualquer usuário do OS/360 logo se dá conta de quanto o sistema pode ser me-
lhor. As falhas de projeto e execução existem, sobretudo no programa de contro-
le, à diferença dos compiladores de linguagens de programação. A maioria dessas
falhas datam do período de projeto, entre 1964-65, e, por isso, cabe a mim a cul-
pa. Além disso, o projeto atrasou, consumiu mais memória do que o planejado,
os custos muitas vezes superaram a estimativa e o sistema não funcionou bem até
o lançamento de várias versões depois da primeira.
Após deixar a IBM em 1965 e transferir-me para Chapel Hill, como era o
combinado quando assumi o OS/360, comecei a analisar essa experiência com o
intuito de tirar lições técnicas e de gestão. Mais especificamente, eu queria expli-
car a sensível diferença entre as experiências de gestão durante o desenvolvimento
de hardware do System/360 e de software do OS/360. Este livro é a resposta tar-
dia para as questões polêmicas levantadas por Tom Watson* sobre as razões pelas
quais é difícil gerenciar tarefas de programação.
Nessa busca, aproveitei as longas conversas com R. P. Case, auxiliar da ge-
rência entre 1964-65, e com F. M. Trapnell, gerente entre 1965-68. Comparei as
conclusões com outros gerentes de projetos gigantes de programação, incluindo
F. J. Corbato do M.I.T., John Harr e V. Vyssotsky da Bell Telephone Labora-
tories, Charles Portman da International Computers Limited, A. P. Ershov do
Laboratório de Computação da Divisão Siberiana da Academia de Ciências da
ex-União Soviética, e A. M. Pietrasanta da IBM.
Minhas conclusões estão nos ensaios a seguir, que têm como público-alvo
programadores profissionais, gerentes profissionais e, sobretudo, gerentes profis-
sionais de programadores.

* Thomas J. Watson foi contratado em 1914 como o primeiro CEO da empresa que, em 1924, passou a chamar-se Inter-
national Business Machines Corporation (IBM). Ele aposentou-se em meados dos anos 50, quando seu filho Thomas
J. Watson Jr. tornou-se o CEO da empresa até se aposentar, aos 60 anos de idade. As referências a Tom Watson, neste
livro, dizem respeito a Thomas J. Watson Jr.

O mitico homem-mes - cad 0.indd xii 15/06/2009 17:57:59

 Prefácio da primeira edição xiii

Mesmo escrito na forma de ensaios separados, o livro encerra um argumen-

to central contido principalmente entre os Capítulos 2 e 7. Fazendo uma breve
análise, creio que os grandes projetos de programação sofrem de problemas de
gestão por serem de natureza diferente dos projetos pequenos, levando em conta
a divisão do trabalho. Acredito na necessidade crítica de se preservar a integrida-
de conceitual do produto a ser desenvolvido. Estes capítulos exploram tanto as
dificuldades em atingir tal unidade como os métodos para consegui-la. Os capí-
tulos mais ao final do livro examinam outros aspectos da gestão de engenharia
de software.
A literatura nesse campo não é abundante e está bastante espalhada. Por isso,
tentei fornecer referências que irão esclarecer alguns pontos em particular e guiar
o leitor interessado em outras obras úteis. Muitos amigos leram o manuscrito e
alguns prepararam extensos e valiosos comentários. Quando não consegui incluí-
los no fluxo do texto, coloquei-os nas Notas.
Como este é um livro de ensaios e não um texto, todas as referências e notas
foram transferidas para o final do volume. Os leitores estão convidados a ignorá-
las em sua primeira leitura.
Estou em profundo débito com a Sara Elizabeth Moore, o David Wagner
e a Rebecca Burris pela ajuda na preparação do manuscrito, e com o Professor
Joseph C. Sloane pelos conselhos nas ilustrações.

F. P. B. Jr.
Chapel Hill, N.C.
Outubro de 1974

O mitico homem-mes - cad 0.indd xiii 15/06/2009 17:57:59

 Apresentação

Desenvolvimento de Software é uma arte e deman-

da muita criatividade. Mas essa
criatividade só traz bons frutos se for embasada em muita técnica, conhecimen-
to científico, raciocínio lógico-matemático e boas práticas de engenharia. Além
disso, quem escreve software são seres humanos, quase sempre trabalhando em
grupos heterogêneos em torno de um projeto comum; com isso, as interações
sociais entre as pessoas envolvidas no projeto e as suas características individuais
têm um papel fundamental no sucesso da empreitada.
Tudo isso faz com que o desenvolvimento de software seja muito menos
previsível e mais difícil de gerenciar do que outras atividades de construção que
geram como produto final um bem material. Software são ideias, bens imateriais,
um produto puramente intelectual.
A primeira obra literária de grande impacto que expôs claramente essa
peculiaridade da indústria de software foi O Mítico Homem-Mês, de Frederick
Brooks Jr. Apesar de ter tido sua primeira edição publicada há mais de 30 anos,
o livro continua surpreendentemente atual. Aprendemos muito com ele, certa-
mente, mas boa parte das dificuldades descritas por Brooks na primeira edição do
livro, em 1975, e refinadas na segunda edição, em 1995, continuam mais atuais
do que gostaríamos.
Brooks, ganhador do prêmio Turing da ACM (o Nobel da Ciência da Com-
putação) de 1999 pelas suas contribuições marcantes à Arquitetura de Compu-

O mitico homem-mes - cad 0.indd xv 15/06/2009 17:58:01

 xvi O mítico homem-mês

tadores, Sistemas Operacionais e Engenharia de Software, apresenta neste livro

ideias nem sempre intuitivas. Adicionar mais pessoas a um projeto atrasado o
torna ainda mais atrasado. O segundo sistema que um arquiteto projeta é o mais
perigoso. Integridade conceitual é a consideração mais importante no projeto de
sistemas. Planeje jogar fora a primeira implementação. Pergunta: como um pro-
jeto atrasa um ano? Resposta: um dia de cada vez. Os participantes de um projeto
devem se comunicar o máximo possível através de telefone, reuniões presenciais,
um livro de trabalho escrito colaborativamente (wiki?) etc. É impossível, para um
cliente, especificar completamente e precisamente os requisitos de um software
antes que esse software tenha sido construído e que o cliente tenha usado e testa-
do algumas de suas versões.
Muitas dessas ideias não convencionais serviram de base para a criação, no
final da década de 1990, de uma nova escola de desenvolvimento de software,
o movimento Ágil. Os cada vez mais populares Métodos Ágeis de Desenvolvi-
mento de Software apresentam, de uma forma sistematizada, um conjunto de
boas práticas para a criação de software de qualidade de forma ágil e adaptativa
que são fortemente baseados em algumas das ideias propostas por Brooks neste
livro seminal.
Aqueles que estão envolvidos diariamente com projetos de desenvolvimento
de software vão identificar neste livro muitos dos problemas corriqueiros de seu
trabalho. Os estudantes que ainda estão se preparando para entrar nessa indús-
tria, encontrarão no livro uma prévia do que lhes espera, permitindo que eles se
“preparem para o pior”. Já para os gerentes de projetos de software, a leitura deste
livro deveria ser obrigatória! Quem sabe assim, O Mítico Homem-Mês passe a ser,
um dia, apenas um livro histórico e não mais um retrato do cotidiano atual de
milhares de projetos da indústria de TI.

Fabio Kon
Departamento de Ciência da Computação
Instituto de Matemática e Estatística
Universidade de São Paulo
São Paulo, junho de 2009

O mitico homem-mes - cad 0.indd xvi 15/06/2009 17:58:01

 Sumário

Prefácio da edição de 20o aniversário vii

Prefácio da primeira edição xi
Apresentação xv
Fred Brooks, entrevista exclusiva à edição brasileira xvii

1. O Poço de Alcatrão 1
2. O Mítico Homem-Mês 11
3. A Equipe Cirúrgica 25
4. Aristocracia, Democracia e o Projeto de Sistemas 37
5. O Efeito do Segundo Sistema 49
6. Transmitindo a Mensagem 57
7. Por que a Torre de Babel Falhou? 69
8. Prevendo o Lançamento 81
9. Dez Quilos em um Saco de Cinco 91
10. A Hipótese dos Documentos 101

O mitico homem-mes - cad 0.indd xix 15/06/2009 17:58:02

 xx O mítico homem-mês

11. Inclua em Seus Planos o Verbo Descartar 109

12. Ferramentas Afiadas 119
13. O Todo e as Partes 133
14. Incubando uma Catástrofe 145
15. A Outra Face 155
16. Não Existe Bala de Prata – Essência e Acidente em
Engenharia de Software 171
17. “Não Existe Bala de Prata” – Mais um Tiro 197
18. Proposições de O Mítico Homem-Mês: Verdadeiras ou Falsas? 219
19. O Mítico Homem-Mês, 20 anos depois 243
Epílogo. Cinquenta anos de Fascínio, Emoção e Prazer 279

Notas e referências bibliográficas 281

Indice 291
Sobre o autor 301

O mitico homem-mes - cad 0.indd xx 15/06/2009 17:58:02

 1
O Poço de Alcatrão

O mitico homem-mes.indd 1 15/06/2009 16:02:28

 1
O Poço de Alcatrão*

Een schip op het strand is een baken in zee.

[Um navio na praia é um farol para o mar.]
provérbio holandês

* Os poços de alcatrão (piche) de La Brea, na Califórnia, compõem um sítio arqueológico onde muitos animais pré-
históricos foram descobertos. Os animais caíam nos poços que afloravam à superfície e não conseguiam mais sair,
afundando enquanto se debatiam. (N. T.)

O mitico homem-mes.indd 3 15/06/2009 16:02:42

 Nenhuma cena da pré-história é tão vívida quanto a das batalhas
mortais que as grandes feras travavam nos poços de
alcatrão. Com os olhos da imaginação é possível ver dinossauros, mamutes e ti-
gres de dentes de sabre lutando para se desvencilhar do piche. Quanto mais feroz
a luta, mais envolvente era o alcatrão. E como nenhum animal era tão forte ou
habilidoso, todos terminavam afundando no poço.
Nas últimas décadas, os trabalhos de programação de grandes sistemas asse-
melham-se à luta num poço de alcatrão onde muitas bestas grandes e poderosas
caíram violentamente. Muitos emergiram com sistemas funcionando – poucos
atingiram seus objetivos, agendas e orçamentos. Grandes e pequenas, extensas
ou concisas, uma equipe após a outra viu-se presa no alcatrão. Não é apenas um
aspecto que parece ser a causa dessa dificuldade – cada pata, individualmente,
pode ser puxada para fora. Mas a acumulação de fatores simultâneos e interativos
diminui o movimento cada vez mais. Todos parecem ter sido pegos de surpresa
por esse problema grudento, cuja natureza é difícil de determinar. Mas nós temos
de tentar entendê-lo se pretendemos solucioná-lo.
Com essa finalidade, vamos começar pela identificação da arte de programa-
ção de sistemas e as alegrias e tristezas inerentes a ela.

O Produto da Programação de Sistemas

Ao ler um jornal a esmo, alguém poderá se dar conta de que dois progra-
madores em uma garagem remodelada construíram um importante programa
que supera os melhores esforços de grandes equipes. E todo programador está
preparado para acreditar em tais histórias, porque ele sabe que poderia construir
qualquer programa muito mais rápido do que aqueles que são feitos com as mil
declarações por ano relatadas por equipes do setor.

O mitico homem-mes.indd 4 15/06/2009 16:02:42

 O Poço de Alcatrão 5

Por que então não substituir todas as equipes de programação por dedicadas
duplas de garagem? É necessário examinar o que está sendo produzido.
No canto superior esquerdo da Figura 1.1 está um programa. Ele está com-
pleto, pronto para ser executado pelo autor no sistema para o qual foi desen-
volvido. É isso que costuma ser produzido em garagens e este é o objeto que o
programador individual utiliza ao estimar produtividade.

X3

Um Um Sistema de
Programa Programas

(Interfaces de Integração
de Sistemas)

X3

Um Um Produto da
Programa Programação de
Produto Sistemas

(Generalização, Testes,
Documentação,
Manutenção)

FIGURA 1.1 Evolução do produto da programação de sistemas

Há duas formas de um programa ser convertido em um objeto mais útil, mas

mais caro. Estas duas formas estão representadas pelos limites no diagrama.
Indo para baixo, atravessando o limite horizontal, um programa torna-se um
programa produto. Este é um programa que pode ser executado, testado, reparado
e estendido por qualquer um. É utilizável em muitos ambientes operacionais,
para muitos conjuntos de dados. Para tornar-se um programa produto utilizável
genericamente, o programa deve ser escrito de uma maneira generalizada. Mais

O mitico homem-mes.indd 5 15/06/2009 16:02:42

 6 O Mítico Homem-Mês

especificamente, o alcance e o formato de entradas devem ser generalizados tanto

quanto o algoritmo básico razoavelmente permitir. Depois, o programa deve ser
efetivamente testado de modo que se possa confiar nele. Isso significa que uma
base substancial de casos de testes, explorando a extensão das entradas e testando
seus limites, deve ser preparada, executada e registrada. Finalmente, a promoção
de um programa para um programa produto requer uma cuidadosa documenta-
ção, de forma que qualquer um possa utilizá-lo, corrigi-lo e estendê-lo. Como
regra geral, eu estimo que um programa produto custe ao menos três vezes mais
do que um programa, já depurado, que tenha a mesma função.
Movendo-se pelo limite vertical, um programa torna-se componente de um
sistema de programas. Tal sistema consiste em uma coleção de programas que
interagem de forma coordenada em sua função e disciplinada em seu formato,
de maneira que o conjunto constitua um ambiente completo para a execução
de grandes tarefas. Para tornar-se componente de um sistema de programas, um
programa deve ser escrito de forma que todas as entradas e saídas estejam em con-
formidade com a sintaxe e semântica do sistema, com interfaces precisamente de-
finidas. O programa também deve ser projetado para usar apenas uma quantidade
determinada de recursos – espaço em memória, dispositivos de entrada e saída,
tempo de processamento. Finalmente, o programa deve ser testado em conjunto
com outros componentes do sistema em todas as combinações previstas. O teste
deve ser extensivo, já que o número de casos cresce de forma combinatória. Tudo
isso consome tempo, pois problemas sutis surgem a partir de interações inespera-
das com componentes já depurados. O componente de um sistema de programas
custa ao menos três vezes mais do que um programa isolado que realiza a mesma
função. O custo pode ser maior se o sistema tiver muitos componentes.
No canto inferior direito da Figura 1.1 está o produto da programação de
sistemas. Este diferencia-se do simples programa de todas as formas descritas an-
teriormente. Ele custa nove vezes mais. Mas ele é o objeto verdadeiramente útil,
o produto pretendido da maioria dos esforços de programação de sistemas.

As Alegrias da Arte
Por que é divertido programar? Que alegrias o praticante dessa arte pode ter
como recompensa?
A primeira é a satisfação de construir algo. Da mesma maneira que uma
criança delicia-se com seu bolinho de lama, os adultos divertem-se construindo

O mitico homem-mes.indd 6 15/06/2009 16:02:44