Uma ultima questao interessante discutida neste capitulo e a alternativa para o desenvolvimento rapido proposto pelo autor, uma abordagem que eu ja vi ser empregada mais vezes do que gostaria.Uma abordagem que poderia ser chamada de sangue, suor e lagrimas (o autor chama tambem de "codificacao dos infernos" ou "codificacao infernal"). "Reune-se a melhor equipe possivel, exige-se compromisso com o projeto, concede-se autonomia proxima da absoluta, motiva-se a equipe ao extremo e espera-se que trabalhem 60h, 80h ou mesmo 100h por semana ate que o projeto ou a equipe se acabem".Como o autor mesmo frisa, algumas vezes isto ate da certo. Infelizmente, na maioria dos casos o resultado e a frustracao generalizada: clientes nao obtem o produto desejado, a equipe fica frustrada porque nao tem seu esforco reconhecido, os gerentes de TI ficam com a imagem desgastada, ...As causas do fracasso sao bem conhecidas: Abordagem do tipo tudo-ou-nadaProblemas com a motivacao no longo prazoNao e repetivelNao privilegia planejamento, coordenacao e cooperacao: depende de "herois" para alcancar seus resultados.Desperdicio extravagante de recursos humanos: os participantes deste tipo de projeto abandonam familias, amigos, hobbies e eventualmente a proprio cuidado com a saude. Conflitos de personalidade sao a regra ao inves da excecao.Esta abordagem e baseada no conceito de "codificacao infernal" e e relativamente popular porque:requer poucos conhecimentos alem do de codificacaoproclama que leva a um desenvolvimento incrivelmente rapidoconfere uma aura de "genialidade" aos desenvolvedoresaparenta que o maximo esta sendo feito pela equipeE tao antiga quanto o desenvolvimento de sistemas em si.Mas a verdade e que:e muito arriscada, falha ate em condicoes de relativo controledesgasta rapidamente os recursos humanoso progresso geral do projeto nao e visivela comunicacao e a coordenacao entre os participantes virtualmente inexiste e leva a muito retrabalho (por erro e por dupla codificacao)depende de herois e conflitos de "egos" sao frequentes.O que este capitulo descreve e a minha experiencia profissional. Fui "heroi" em alguns projetos, sacrifiquei minha vida pessoal, trabalhei 16 horas por dia semanas a fio, entrei em conflitos desnecessarios com pessoas tao comprometidas quanto eu e vi projetos fracassarem. Fiquei muito frustrado quando apesar de todos os esforcos os clientes se mostravam insatisfeitos e algumas pessoas julgavam a situacao absolutamente natural!! Como se o desenvolvimento de sistemas devesse sempre fracassar, como se nada pudesse ser feito para mudar.Eu me rebelei contra esta situacao mas e muito complicado mudar a cultura institucional, principalmente quando o "trato com as pessoas" nao e uma de suas habilidades mais desenvolvidas. Este capitulo nao e muito longo mas e rico em detalhes. Antes de tecer qualquer comentario preciso refletir um pouco O livro ficou dois anos mais velho mas nao deixou de conter muitas verdades.Vou retomar o projeto de onde parei, sempre que que possivel as tercas e sabados.Ate breve, Segundo o autor, o segredo do sucesso esta na excelencia dos fundamentos. Uma coisa, para ser bem feita, precisa ao menos ser feita. Em razao disto, o sucesso dos projetos depende da perfeita execucao dos fundamentos gerenciais, tecnicos e de controle de qualidade.Os fundamentos gerenciais sao:estimativa do tamanho do produto (funcionalidades, complexidade)alocacao de recursos para