Quanto custa a correção de bugs no desenvolvimento de softwares? Depende de quão tarde você irá descobri-los!
A máxima da prevenção é melhor do que a cura não vale só na medicina! A frase do erudito holandês Desiderius Erasmus é bem oportuna também na indústria de desenvolvimento de sistemas.
Veremos que o custo de corrigir um bug é muito maior do que criar mecanismos para evitá-los. Entenda como bug tudo que é um defeito ou problema, desde a concepção até o pleno uso de um sistema. Seus desenvolvedores também o chamam de pau, probleminha, usuário, negocinho, e por aí vai. É provável que esteja se lembrando das frases clássicas de um desenvolvedor quando você encontra um problema e ouve: “no meu computador funciona”, “você está fazendo alguma coisa errada” ou “aperta F5” ...
Por mais engraçado que isso pareça, situações como estas ocultam problemas que se não forem resolvidos rapidamente sairão muito caro, não só financeiramente, como também para a imagem de sua empresa e de seu time de desenvolvimento.
Na medicina, curar é muito mais caro e traumático do que prevenir. Em tecnologia não é diferente: quanto mais cedo um bug for encontrado mais fácil e menos impactante é sua correção.
O problema é que a evidência tem mostrado que defeitos em softwares é um fator inerente na indústria de tecnologia. Um artigo da Coralogix relata que 75% do tempo dos desenvolvedores estão voltados em debugar código para descobrir e consertar problemas.
A estimativa é de que a cada 1000 linhas de código criadas, 70 novos bugs são criados e 15 serão descobertos pelo seu cliente. E se isso de fato acontecer, cada bug corrigido em sistemas que estão em produção custará 30 vezes mais (tempo e dinheiro) para serem corrigidos do que se tivessem sido descobertos na fase de desenvolvimento.
Porém, alguns podem custar bem mais:
- (2007) - Arquivos do projeto FBI Virtual: Custo de US$170 milhões.
- (2004) - Erro em software do Reino Unido destrói registros fiscais: Custo de no mínimo £85 milhões.
- (2004) - Projeto de software da Ford e Oracle desaba: Custo US$400 milhões.
- (1962) - Falha em foguete por falta de um hífen: Custo de US$135 milhões.
Aqui na Interaktiv discutimos frequentemente sobre testes automatizados e seus benefícios e o quão importante eles são para a causa. Como focamos no desenvolvimento web e mobile estão sempre no radar testes voltados para:
- Teste de aplicativos Web
- Testes de aplicativos móveis
- Testes de performance
- Testes de serviços (transações e regras de negócio)
- Testes de código (BDD/TDD)
Entendemos que o problema é mais em baixo e não são apenas os desenvolvedores os únicos causadores de bugs e defeitos em sistemas. Na verdade, o desenvolvimento representa apenas uma parte dos problemas como vemos no gráfico abaixo:
Há um consenso de todas as partes envolvidas no processo (incluindo o cliente) de que não há nada mais nocivo para um projeto do que uma especificação mal feita. E aí meu amigo, como já diria o filósofo Compadre Washington: pau que nasce torto nunca se endireita! A falta de organização no levantamento de requisitos, subdimensionamento das demandas e detalhamento superficial é uma bomba relógio que vai explodir mais cedo ou mais tarde.
Portanto, não há uma solução de varinha mágica. É necessário fazer parte da cultura da empresa processos que previnam defeitos, e isso começa do começo. É necessário traduzir os requisitos do cliente de forma clara para que a arquitetura da solução, a revisão do código e os testes tenham base concreta para minimizar os problemas que certamente serão descobertos em outras fases do projeto.
Crie uma base de dados de problemas e discuta com o seu time as lições aprendidas. Escolha uma metodologia ágil para gerenciar o fluxo do projeto e motive toda a equipe a minimizar os erros. Porém, quando os acharem, incentive-os a não jogá-los debaixo do tapete mas resolve-los o quanto antes. Isso certamente economizará algumas noites de sono de todos.
Em matéria de incentivo aqui vai uma ideia do chefe do Dilbert:
Existem muitas ferramentas projetadas para aumentar a produtividade e diminuir falhas como XP, TDD, Agile, Scrum, etc. Porém, assim como a diferença entre a vacina e o veneno é a dose, saiba dosar tudo isso em um modelo hÍbrido que se encaixe na operação de sua empresa.
Encontre mecanismos de medição para analisar a quantidade de bugs que entram e saem. Analise as recorrências e reúna a equipe para discutir como evita-las. Os resultados não virão de um dia para o outro, mas quem definirá a velocidade dessa transição será a capacidade que você e sua equipe têm de aprender com os erros, ou melhor, com os bugs.
