Revisitando os fatos e as falácias da engenharia de software

Gosto de reler meus livros favoritos a cada poucos anos, por isso trouxe o livro seminal de Robert Glass Facts and Fallacies of Software Engineering (Fatos e Falácias da Engenharia de Software) comigo em minha viagem mais recente. Achei que era uma leitura decente, mas imperfeita, quando o comprei originalmente em 2004. Ao folhear a introdução e o índice, percebi que Já escrevi sobre quase tudo nesse livro até agora.

Não sei se dei o devido valor a Facts and Fallacies em minha primeira leitura.

A simples recitação dos vários fatos e falácias parece um koan zen para a engenharia de software. Mesmo sem qualquer discussão e explicação de fundo no livro, é terapêutico ponderar sobre os breves resumos de uma frase apresentados no índice. Ao lê-los, o que lhe vem à mente, com base em sua experiência?

Pessoas

1. O fator mais importante no trabalho com software é a qualidade dos programadores.
2. Os melhores programadores são até 28 vezes melhores do que os piores programadores.
3. Adicionar pessoas a um projeto atrasado o torna mais atrasado.
4. O ambiente de trabalho tem um impacto profundo na produtividade e na qualidade.

Ferramentas e técnicas

5. O hype (sobre ferramentas e tecnologia) é uma praga na casa do software.
6. Novas ferramentas e técnicas causam uma perda de produtividade/qualidade.
7. Os desenvolvedores de software falam muito sobre ferramentas, mas raramente as utilizam.

Estimativa

8. Uma das duas causas mais comuns de projetos em andamento é a estimativa ruim.
9. A estimativa de software geralmente ocorre no momento errado.
10. A estimativa de software geralmente é feita pelas pessoas erradas.
11. As estimativas de software raramente são corrigidas à medida que o projeto avança.
12. Não é de surpreender que as estimativas de software sejam ruins. Mas, mesmo assim, vivemos e morremos por elas!
13. Há uma desconexão entre o gerenciamento de software e seus programadores.
14. A resposta para um estudo de viabilidade é quase sempre “sim”.

Reutilização

15. A reutilização em pequena escala é um problema resolvido.
16. A reutilização em grande escala continua sendo um problema não resolvido.
17. O reuse-in-the-large funciona melhor em famílias de sistemas relacionados.
18. Os componentes reutilizáveis são três vezes mais difíceis de construir e devem ser testados em três ambientes diferentes.
19. A modificação do código reutilizado é particularmente propensa a erros.
20. A reutilização de padrões de projeto é uma solução para os problemas de reutilização de código.

Requisitos

23. Uma das duas causas mais comuns de projetos em fuga são os requisitos instáveis.
24. Os erros de requisitos são os mais caros de serem corrigidos durante a produção.
25. A falta de requisitos é o erro de requisitos mais difícil de corrigir.

Design

26. Os requisitos explícitos “explodem” à medida que os requisitos implícitos de uma solução evoluem.
27. Raramente há uma única solução de design ideal para um problema de software.
28. O design é um processo complexo e iterativo. As soluções iniciais de design geralmente estão erradas e certamente não são ideais.

Codificação

29. As “primitivas” do designer raramente correspondem às “primitivas” do programador.
30. O COBOL é uma linguagem muito ruim, mas todas as outras são muito piores.

Remoção de erros

31. A remoção de erros é a fase mais demorada do ciclo de vida.

Testes

32. Normalmente, o software é testado, na melhor das hipóteses, até o nível de cobertura de 55 a 60%.
33. 100% de cobertura de teste ainda está longe de ser suficiente.
34. As ferramentas de teste são essenciais, mas raramente utilizadas.
35. A automação de testes raramente é usada. A maioria das atividades de teste não pode ser automatizada.
36. O código de depuração incorporado, criado pelo programador, é um complemento importante para as ferramentas de teste.

Revisões e inspeções

37. Inspeções rigorosas podem eliminar até 90% dos erros antes que o primeiro caso de teste seja executado.
38. As inspeções rigorosas não devem substituir os testes.
39. As revisões pós-entrega, postmortems e retrospectivas são importantes e raramente realizadas.
40. As revisões são tanto técnicas quanto sociológicas, e ambos os fatores devem ser acomodados.

Manutenção

41. A manutenção normalmente consome de 40 a 80% dos custos de software. É provavelmente a fase mais importante do ciclo de vida do software.
42. Os aprimoramentos representam cerca de 60% dos custos de manutenção.
43. A manutenção é uma solução, não um problema.
44. Entender o produto existente é a tarefa de manutenção mais difícil.
45. Métodos melhores levam a mais manutenção, não menos.

Qualidade

46. A qualidade é um conjunto de atributos.
47. Qualidade é não a satisfação do usuário, o atendimento aos requisitos, o cumprimento do custo e do cronograma ou a confiabilidade.

Confiabilidade

48. Há erros que a maioria dos programadores tende a cometer.
49. Os erros tendem a se agrupar.
50. Não existe uma abordagem única e melhor para a remoção de erros de software.
51. Os erros residuais sempre persistirão. O objetivo deve ser minimizar ou eliminar graves erros.

Eficiência

52. A eficiência decorre mais de um bom design do que de uma boa codificação.
53. O código de linguagem de alta ordem pode ser cerca de 90% mais eficiente do que um código assembler comparável.
54. Há compensações entre otimizar o tempo e otimizar o espaço.

Pesquisa

55. Muitos pesquisadores defendem em vez de investigar.

Eu havia me esquecido do quanto o livro cobre; é um trampolim perfeito para todos os tópicos essenciais da engenharia de software.

Já postei sobre quase todos esses fatos nos quatro anos que se passaram desde que os li originalmente. Quando me debrucei sobre o índice apresentado acima, mal pude me conter. Lembrei-me e, mentalmente, marquei cada postagem da lista à medida que avançava: marquei, marquei, marquei. No passado, fui acusado de fazer links gratuitos para mim mesmo, portanto, não vou encher as regras com dezenas de links para minhas publicações antigas sobre esses tópicos. Se o senhor estiver interessado, poderá encontrá-los. Esse é mais ou menos o objetivo.

Se esses são os cinquenta e cinco fatos, então esses são os dez falácias apresentadas no final. As falácias têm a anel de verdade, mas, após uma inspeção mais minuciosa, acabam sendo problemáticas quando aplicadas a um projeto de software real.

1. O senhor não pode gerenciar o que não pode medir.
2. O senhor pode gerenciar a qualidade em um produto de software.
3. A programação pode e deve ser sem ego.
4. Ferramentas e técnicas: um tamanho único para todos.
5. O software precisa de mais metodologias.
6. Para estimar o custo e o cronograma, primeiro estime as linhas de código.
7. A entrada de testes aleatórios é uma boa maneira de otimizar os testes.
8. “Se o senhor tiver olhos suficientes, todos os bugs são superficiais”.
9. A maneira de prever futuros custos de manutenção e tomar decisões sobre a substituição de produtos é examinar os dados de custos anteriores.
10. O senhor ensina as pessoas a programar mostrando a elas como escrever programas.

Se o senhor estiver curioso sobre a lógica por trás desses fatos e falácias, essa é a razão da existência do livro: lembrar-nos de questionar o que estamos fazendo. Deveríamos pensar sobre nosso ofício todos os dias, de alguma forma, em nossos próprios projetos de software. É assim que avançamos coletivamente na engenharia de software – construindo nossa memória e história compartilhadas no campo. Como o Sr. Glass afirma na introdução:

Ao apresentar esses fatos, também estou identificando problemas no campo. Não é minha intenção apresentar soluções para esses problemas. Este é um livro sobre o que é, não um livro sobre como fazer. Isso é importante para mim. Quero trazer esses fatos à tona, onde eles possam ser discutidos livremente e possamos agir com base neles para progredir.

Incentivo os senhores a pegar uma cópia do livro completo para uma exploração mais profunda. Acredito que há uma rica experiência de aprendizado – ou uma rica experiência de recordação – aqui para os senhores que decidirem continuar lendo.