São muitas as razões que podem ser citadas para o fracasso de projetos de software. Alguns projetos falham devido a requisitos ruins, outros devido ao custo e um cronograma super estimado e alguns simplesmente devido à um mau gerenciamento. Se fizermos uma análise da causa principal bem a fundo, será que todos os projetos que falham, o principal culpado é o código ruim? Sempre?
Uncle Bob acredita que o custo de se ter um código ruim é muito alto, podendo fazer com que um projeto falhe. Segundo ele,
Eu conheço projetos que falharam por causa de código. Na verdade, eu conheço empresas que fracassaram por causa de código.
De acordo com Bob, o raciocínio é bem simples. Se o custo para manter o código exceder o orçamento do projeto, então, o projeto falha e se o custo ultrapassa o orçamento da empresa, então, a empresa também falha. Tomando um outro extremo Bob sugere que se o custo do código for próximo de zero, então, nenhum projeto poderia fracassar.
Porque os projetos falham devido a maus requisitos, mau gerenciamento, mau planejamento e orçamentos ruins? Eles falham porque o custo do erro é enorme. E porque que o custo do erro é enorme? Porque o custo do código é terrivelmente grande. Se não custa nada produzir o código, o custo do erro seria próximo de zero.
No entanto, nem todos concordam com esta idéia.
Quando essa questão foi colocada no Twitter, a maioria das pessoas concordaram que as questões relacionadas a negócios foram as principais causas de fracassos de projetos. Alex Chaffee sugeriu que um mau gerenciamento e maus requisitos não podem ser superados por um bom código.
Se você tem maus requisitos e uma má gestão, então agora mesmo livre-se de tudo isso, um código instantâneo não poderá salvar o seu negócio. Se você implementou de imediato uma versão impecável de um produto inútil que ninguém queria, e depois continuou a rapidamente repetir mais versões horríveis de um produto de baixa qualidade, então você ainda estará eventualmente executando sem tempo, dinheiro e reputação, e seu projeto ou negócio ainda irão falhar.
Do mesmo modo, James Iry disse que um código ruim é apenas uma das razões pelas quais um projeto pode falhar. Segundo ele,
Um código limpo e sem erros, certamente permite a uma empresa iteragir mais rapidamente, mas se ele simplesmente iteragir com idéias ruins, ou com boas idéias que não podem ser vendidas, devido a um marketing ruim, ou que até vende bem, mas que cria uma estrutura de custos muito pesada nas instalações ou na gestão então a empresa eventualmente acabará por fracassar.
Michael Dubakov sugere que os projetos falham por não fornecerem a solução correta. Ele mencionou que, se o código está limpo, seria fácil de refatora-lo novamente para chegar à solução correta, mas isso não implica que um bom código seja a solução correta. Michael sugeriu que,
Você pode criar uma arquitetura absolutamente linda com o código mais limpo do mundo. Você pode ter 100% de cobertura de testes, uma separação de conceitos completa, hierarquias enxutas e métodos sem argumentos booleanos. Você pode ter toda essa beleza, mas continuará a falhar miseravelmente se o programa não resolver os problemas do usuário de forma eficiente.
Michael Norton, acrescentou que uma análise da causa principal de falha de quase todos os fracassos nos levaria as pessoas. De acordo com Michael,
Se um projeto fracassou porque resolveu o problema de forma errada, o projeto fracassou porque as pessoas envolvidas entenderam mal o problema. Se um projeto falhou porque o código é de má qualidade (e alguns produzem códigos ruins), ele falhou porque as pessoas envolvidas colaboraram para escrever um código de baixa qualidade ou pobre.
Assim, embora ninguém despreze a importância de um bom código limpo, nem todos concordam que um código ruim seja o único responsável pela falência de um projeto. O que você acha disso ?