Você nunca é ensinado a construir software de qualidade

Artigo original ↗ Discussão no Hacker News ↗

Muitos engenheiros argumentam que a educação em ciência da computação e os estágios típicos se concentram em algoritmos e em entregar funcionalidades, oferecendo pouca formação sistemática em qualidade de software, testes e manutenibilidade de longo prazo. Os კომენტadores contrastam isso com áreas como aviação e manufatura, que incorporam QA rigoroso e processos de pós‑incidente, mas observam que essas práticas são caras e frequentemente entram em conflito com incentivos de negócio para agir rapidamente. O debate gira em torno de se “qualidade” pode ser ensinada formalmente, quanto só pode ser aprendido pela experiência e como justificar trabalho de QA em organizações que otimizam principalmente por velocidade e resultados de curto prazo.

O que significa “software de qualidade” (e se isso pode ser ensinado)

  • Muitos argumentam que “qualidade” é vago: é confiabilidade, desempenho, manutenibilidade, UX ou valor de negócio?
  • Alguns dizem que a qualidade é aprendida principalmente por meio de prática e feedback, não por teoria de sala de aula.
  • Outros insistem que existe uma disciplina acadêmica e de engenharia (engenharia de software, QA, métodos formais) que ensina qualidade, mas sua adoção é irregular.

Comparações com outras áreas (aviação, manufatura, engenharia)

  • Aviação e manufatura são citadas como exemplos em que a qualidade é ensinada sistematicamente por meio de checklists, regulamentação, análises de incidentes e controles de processo.
  • Alguns sugerem que uma checklist comparável de 500 itens para software reduziria drasticamente bugs, mas mataria a velocidade no estilo startup.
  • Contraponto: mesmo em engenharia “dura”, defeitos, recalls e falhas são comuns; tudo é “bom o suficiente”, não perfeito.

CS universitária vs. Engenharia de Software

  • Reclamação recorrente: cursos de CS focam em algoritmos, compiladores, teoria e sistemas de baixo nível, mas quase não abordam QA, testes, estratégia de depuração ou design de sistemas em larga escala.
  • Outros relatam ter feito cursos sérios de engenharia de software: testes, SDLC, UML, projetos em equipe, capstones que simulam manutenção do mundo real.
  • Há debate sobre se as universidades devem ser treinamento para o trabalho ou educação pura, especialmente diante do aumento das mensalidades e das expectativas do mercado.

QA, testes e processo

  • Tema forte: QA muitas vezes é encaixado no fim (ou ignorado) por pressão de prazo; “sprints de QA” e testes tardios são apontados como anti‑padrões.
  • Defensores propõem: testes escritos junto com o código, CI/CD, automação, testes de snapshot/visuais, cobertura mais testes de mutação/fuzzing e métricas bem pensadas (com consciência da lei de Goodhart).
  • Alguns observam que existem equipes de alta qualidade em que 40–60% do esforço vai para testes e trabalho de qualidade, mas elas não são a norma.

Bugs, alegações de “sem bugs” e métodos formais

  • Consenso: software absolutamente sem bugs é praticamente inatingível além de programas triviais; “zero bugs” é melhor visto como uma assíntota ou como “nenhum defeito conhecido em relação a uma especificação”.
  • Debate sobre definições de “bug” (desvio da especificação vs. qualquer comportamento inesperado) e se erros de especificação contam.
  • Métodos formais e provas podem eliminar classes de defeitos em domínios de segurança crítica, mas são caros, limitados em escopo e não corrigem especificações ruins ou incompletas.

Economia, incentivos e trade-offs

  • Muitos apontam que a gestão costuma priorizar velocidade e funcionalidades visíveis em vez de qualidade, porque métricas de negócio raramente recompensam a manutenibilidade de longo prazo.
  • Os custos da qualidade são difusos e adiados (dívida técnica, equipes lentas, tempo desperdiçado pelo usuário), enquanto o custo de desenvolvimento é imediato e mensurável.
  • Alguns argumentam que, em larga escala, até bugs “raros” se tornam comuns e causam uma “morte por mil cortes”, mas outros afirmam que a maioria dos mercados tolera software medíocre se ele for lançado rápido e resolver um problema.