O código é o culpado! Sempre?

por Vikas Hazrati , traduzido por Marcelo Costa em 17 Dez 2010 |

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 ?

Conteúdo editorial relacioado

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

Comentários da comunidade

Mau Gerenciamento = código ruim by Paulo Moura Posted

Re: Mau Gerenciamento = código ruim by Enrique Souza Posted

Re: Mau Gerenciamento = código ruim by Pedro Henrique Santana Mariano Posted

Re: Mau Gerenciamento = código ruim by Enrique Souza Posted

Re: Mau Gerenciamento = código ruim by Priscila Ribeiro Posted

Re: Mau Gerenciamento = código ruim by Marcelo Costa Posted

Re: Mau Gerenciamento = código ruim by Leandro Lima Posted

Re: Mau Gerenciamento = código ruim by Leandro Alvares da Costa Posted

Código ruim = Desenvolvedor preguiçoso ? by Marcelo Costa Posted

O código é o culpado! Sempre? by marcio duran Posted

Motivação e visão by Wanderson Santos Posted

Mau Gerenciamento = código ruim by Paulo Moura

Na minha opinião, se existe um mau gerenciamento e um mau levantamento de requisitos, inevitavelmente temos um código ruim.

Re: Mau Gerenciamento = código ruim by Enrique Souza

Meu gerenciamento, péssimo projeto... O código ruim é culpa do desenvolvedor

Re: Mau Gerenciamento = código ruim by Enrique Souza

Ops... não meu gerenciamento... MAL..rsrsrsrs

Meu gerenciamento, péssimo projeto... O código ruim é culpa do desenvolvedor

Re: Mau Gerenciamento = código ruim by Pedro Henrique Santana Mariano

Mas em um projeto onde o desenvolvedor não vê prospecção ele tem mais chances de criar código ruim, concorda?

E não sou um dos adeptos ao fato de que um software com código ruim não pode ter sucesso, acho que depende mt dos desenvolvedores e da idéia e do gerenciamento. O que acham?

Re: Mau Gerenciamento = código ruim by Enrique Souza

Concorco 100%. A qualidade do software tem a ver mais com performance e flexibilidade do que com Bugs. Claro que se o código for muito bugado o projeto não vai, entretanto se o código for feio, mas funcionar, o cliente vai ficar satisfeito e vai gastar $ de manutenção a vida toda. Já vi isso em muitas empresas.

Re: Mau Gerenciamento = código ruim by Priscila Ribeiro

Mais uma vez, o trabalho de requisitos tão desprezado, é a grande vedete do sucesso do projeto.

Código ruim é consequencia.

Re: Mau Gerenciamento = código ruim by Marcelo Costa

Eu discordo totalmente que seja um problema de requisitos. Requisitos não é tudo. Você pode ter o melhor time de analistas de requisitos do mundo mas se o ṕroblema não for bem compreendido com toda certeza do mundo vai ter problema no final.

O entendimento do dominio de um problema e sua construção são fundamentais para o sucesso de qualquer projeto código ruim é uma consequência de falta de V & V.

Código ruim = Desenvolvedor preguiçoso ? by Marcelo Costa

Eu já participei de vários times. Times que possuiam bons analistas, bom gerenciamento porém o código sempre era ruim. Apesar de alguns desligamentos, levou muito tempo para que as pessoas que ficaram compreendessem que precisavam estudar mais e se dedicar aos seus projetos.

Muitas vezes vejo programadores com anos de trabalho (e não de experiência) programando mau como se ainda estivessem entrando no mercado. Isso também se reflete a gerentes e analistas. Mas nesse caso o foco é o código mau desenvolvido, mau criado (literalmente) e com aberrações que com um pouco de conhecimento (diga-se estudo) poderia ser resolvido.

Uma dúvida que sempre me vem em mente é a de que muitos profissionais, após receberem seus canudos e lerem alguns poucos blogs acham que não precisam nunca mais sentar numa escrivaninha, ler um livro ou mesmo fazer um dojo para "aprender". Será que essas pessoas não veem que logo logo serão superados ou desligados ?

Qual a opinião de vocês sobre boas práticas e estudo (educação mesmo, cursos, seminarios, workshops, etc...) ?

Re: Mau Gerenciamento = código ruim by Leandro Lima

Gerenciamento ruim pode implicar a inexistência de controles que evidenciem baixa qualidade do código, que pode levar a um fracasso do projeto.

Mas, mesmo com bom gerenciamento, ainda assim o projeto pode falhar.

É a famosa expressão: "Faça a coisa certa, do jeito certo".

De nada adianta fazer a coisa errada do jeito certo (código lindo, requisitos pobres).

E de nada adianta fazer a coisa certa do jeito errado (bom produto/requisitos, código pobre).

A virtude está no caminho do meio.

Re: Mau Gerenciamento = código ruim by Leandro Alvares da Costa

@Leandro Lima

Concordo plenamente com a sua colocação.
Acredito que ambos os lados tendem a pesar no fracasso de um projeto.

O código é o culpado! Sempre? by marcio duran

Uma vez fiz a seguinte observação , "software não é código é requisito" , mas o que me fez a levar esse pensamento, justamente porque você deve compreender onde , "o caso de uso de seu cliente se encontra" à se pensar em confeccionar o software, e isso é fatal na produção desses objeto(requisito/código) vão sendo estruturados, e antes pensados e testados(TDD),como melhor combina e satisfaz o modelo a ser implementado(DDD), código é industrializado quando esse artefatos são seguramente compreendidos(Modelo foi atendido), e então aceitação ao Domínio.

A visão de arquitetura é o que o desenvolvedor precisa ter e colaborar entre outras responsabilidades(papéis)e esses requisitos(objetos),sempre se reportando com os Stakeholder e o Product Owner decisões ao Projeto,"se você for pensar em código ruim", pense antes se você esta sabendo se comunicar(SCRUM)ou esta ciente que pessoas partilham de suas responsabilidades(erros e acerto), você precisa estar aculturado(envolver-se com todos) tanto com o negócio da sua empresa quanto com a tecnologia envolvida.

Motivação e visão by Wanderson Santos

Equipes motivadas geram bons resultados.

A falta de uma visão unificada da equipe (comunicação e confiança entre os papéis) também é uma das grandes causas do fracasso dos projetos.

Fechar