O processo de qualidade mais eficaz que ninguém usa

Em 1976, Michael Fagan publicou um artigo no IBM Systems Journal descrevendo um processo de revisão tão eficaz que se tornou o padrão ouro para qualidade de software. As Fagan Inspections capturavam de 60 a 90 por cento de todos os defeitos antes que um único teste fosse executado. Um estudo da NASA em 2002 descobriu que cada hora gasta em inspeção prevenia em média 33 horas de trabalho de manutenção posteriormente.

Por qualquer padrão mensurável, este foi o melhor processo de revisão que a engenharia de software já produziu.

Quase ninguém o usa hoje.

A questão não é se as Fagan Inspections funcionavam. Elas funcionavam quase demais. A questão é por que um processo com esse histórico desapareceu do desenvolvimento convencional, e se perdemos algo importante quando o substituímos.

Como as Fagan Inspections realmente funcionavam

Fagan não inventou o code review. Ele inventou um ritual específico e altamente estruturado para encontrar defeitos.

O processo tinha seis fases rígidas:

  1. Planning: Um moderador selecionava os participantes e verificava se o material atendia aos critérios de entrada.
  2. Overview: O autor explicava o contexto. Isso servia para estabelecer o contexto, não para revisar.
  3. Preparation: Cada participante revisava o material de forma independente, a aproximadamente 150 linhas por hora, com uma lista pessoal de defeitos suspeitos.
  4. Inspection Meeting: A equipe se reunia por no máximo duas horas. Um reader narrava a lógica em voz alta. Um recorder registrava os defeitos. O moderador mantinha a reunião focada em encontrar defeitos, não em resolvê-los.
  5. Rework: O autor corrigia cada defeito registrado.
  6. Follow-up: O moderador verificava se as correções foram feitas e se nenhum novo defeito foi introduzido.

Os papéis eram específicos e não sobrepostos. O moderador conduzia o processo, mas não era a autoridade técnica. O reader narrava o código, mas não o defendia. O autor estava presente, mas proibido de explicar sua intenção durante a reunião. O propósito não era colaboração. Era a detecção fria e sistemática de defeitos.

Esta é a parte que o fazia funcionar. A dinâmica social das reuniões normais de engenharia foi eliminada por design.

Por que os números eram tão bons

A taxa de detecção de defeitos não foi um acidente. Ela resultava de algumas escolhas deliberadas de design.

A preparação independente significava que seis pessoas examinavam o mesmo código isoladamente antes que qualquer discussão em grupo pudesse enviesá-las. A sobreposição entre suas listas indicava quão óbvio era um defeito. Os itens que apenas uma pessoa encontrava eram frequentemente os mais valiosos.

O limite rígido de duas horas impedia que a fadiga destruísse o julgamento. Fagan sabia que a eficácia da inspeção cai drasticamente após cerca de duas horas. A taxa de 150 linhas por hora também era deliberada. Mais rápido que isso e você começa a ver o que espera ver, em vez do que realmente está lá.

A regra de não soluções mantinha as reuniões focadas. Nada destrói uma inspeção mais rápido do que uma sala cheia de engenheiros projetando uma correção para um defeito que ainda não caracterizaram completamente.

Essas restrições não eram overhead burocrático. Elas eram o mecanismo. Remova-as e você obtém algo mais amigável, mas menos eficaz.

O que matou as Fagan Inspections

Se o processo era tão eficaz, por que ele desapareceu?

A resposta curta é que ele era caro exatamente da maneira que o desenvolvimento de software moderno se recusa a tolerar.

Uma única Fagan Inspection consumia de 15 a 20 por cento do esforço gasto em escrever o código sendo revisado. Em um caso documentado, 348 linhas exigiram 27,3 horas-pessoa de inspeção. Essa proporção é inconcebível quando as equipes fazem deploy várias vezes ao dia.

Apenas o agendamento era um trabalho em tempo integral. Você precisava de cinco ou seis pessoas em uma sala por duas horas, mais preparation, mais follow-up. Em uma grande organização, encontrar uma janela de duas horas onde um moderador, reader, dois reviewers, recorder e autor estivessem todos disponíveis podia levar dias.

A estrutura rígida de papéis também não escalava. As Fagan Inspections assumiam uma equipe estável com pessoas suficientes para preencher todos os papéis. Em uma startup, uma equipe de cinco pessoas pode não ter ninguém que possa servir como moderador dedicado sem destruir a velocidade.

O maior fator foi cultural. As Fagan Inspections eram deliberadamente desconfortáveis. O autor sentava em silêncio enquanto colegas narravam seu código e registravam seus defeitos. Não havia espaço para “isso é apenas um primeiro rascunho”. O processo assumia que defeitos são caros e fricção social é barata. A engenharia moderna opera sob a suposição oposta.

Com o que as substituímos

A indústria não abandonou a revisão estruturada. Ela a substituiu por pull requests.

A revisão de pull request é assíncrona, de baixa cerimônia, e embutida diretamente no workflow de desenvolvimento. Um reviewer pode olhar um diff entre reuniões, no celular, ou enquanto espera o CI terminar. Não há papéis atribuídos. O autor e o reviewer são frequentemente a mesma pessoa que só precisa de mais uma aprovação para fazer merge.

Isso é uma melhoria massiva em acessibilidade, velocidade e developer experience. Também é uma regressão massiva na detecção de defeitos.

Vários estudos encontraram que a revisão informal captura aproximadamente metade dos defeitos que a inspeção estruturada captura. Um experimento de 2009 de Basili e outros comparou a inspeção estilo Fagan com a revisão lightweight e descobriu que o processo mais leve capturava significativamente menos defeitos no mesmo material.

O problema não é que os reviewers são preguiçosos. O processo não é projetado para encontrar defeitos. Ele é projetado para permitir que as pessoas enviem código com um segundo par de olhos sobre ele, o que não é a mesma coisa.

O que realmente perdemos

A revisão de pull request otimiza o throughput. A inspeção Fagan otimizava a minuciosidade. Esses são objetivos genuinamente diferentes, e nenhum está errado. O erro é assumir que o processo mais leve é um superconjunto estrito do mais pesado.

Aqui está o que desapareceu:

Preparação independente. Em um pull request, o reviewer vê o diff a frio. Ele não passou uma hora lendo o contexto ao redor, rastreando o fluxo de dados e construindo um modelo mental. Ele está reagindo a uma notificação. A profundidade do exame não é comparável.

O papel de reader. Fazer alguém narrar o código em voz alta força o grupo a proceder num ritmo que a pessoa mais lenta pode acompanhar. Ele revela suposições que a leitura silenciosa esconde. Um diff numa tela deixa seus olhos pular as partes chatas. Um reader não pula.

Foco apenas em defeitos. Os comentários de pull request derivam para opiniões de estilo e arquitetura. Essas são valiosas, mas não são detecção de defeitos. Cada minuto gasto debatendo indentação é um minuto não gasto encontrando um null dereference.

Dados de processo mensuráveis. As Fagan Inspections produziam números concretos: defeitos por hora, tempo de preparation, tempo de rework, defect density por module. As ferramentas modernas de revisão contam comentários e aprovações, que não dizem quase nada sobre a qualidade da revisão.

Um meio-termo prático

Você não vai executar Fagan Inspections completas num ambiente de continuous deployment moderno. Mas pode emprestar as partes que importam.

A ideia transferível mais importante é a preparação independente estruturada. Antes de uma revisão async profunda, exija que os reviewers passem tempo com o material sozinhos. Não uma leitura rápida. Preparation de verdade.

Em vez de um “LGTM” genérico, imponha uma checklist lightweight que imite a disciplina que Fagan construiu em papéis e regras:

from dataclasses import dataclass, field
from typing import List, Optional
from enum import Enum

class DefectSeverity(Enum):
    MINOR = "minor"
    MAJOR = "major"
    CRITICAL = "critical"

@dataclass
class ReviewEntry:
    line_number: Optional[int]
    category: str
    severity: DefectSeverity
    description: str

@dataclass
class InspectionReport:
    reviewer: str
    prep_time_minutes: int
    entries: List[ReviewEntry] = field(default_factory=list)

    def defect_count(self) -> int:
        return len(self.entries)

def run_inspection_checklist(
    code: str,
    reviewer: str,
    prep_time_minutes: int
) -> InspectionReport:
    """Structured prep produces structured output.

    Mimics the Fagan prep phase: reviewer spends focused
    time with the material, then logs findings against a
    consistent taxonomy instead of ad hoc comments.
    """
    report = InspectionReport(
        reviewer=reviewer,
        prep_time_minutes=prep_time_minutes
    )

    # Example: check for missing null handling
    if "->" in code and "null" not in code.lower():
        report.entries.append(ReviewEntry(
            line_number=None,
            category="null-safety",
            severity=DefectSeverity.MAJOR,
            description="No explicit null handling in pointer function"
        ))

    return report

Isso não é uma Fagan Inspection. É uma forma de recuperar uma de suas propriedades mais importantes: o output de revisão deve ser estruturado, mensurável e focado em categorias de defeitos em vez de opiniões.

Outra ideia transferível é a revisão profunda time-boxed. Escolha um module crítico por sprint. Agende uma revisão focada de 90 minutos com preparation independente. Registre apenas defeitos. Sem soluções, sem debates de estilo, sem argumentos de design.

O custo é real. Mas se a proporção da NASA se mantiver mesmo aproximadamente, uma hora focada agora economiza dezenas de horas de debugging depois.

A verdade desconfortável

As Fagan Inspections não falharam. Elas foram rejeitadas porque a rigorosidade que exigiam era incompatível com a velocidade que a indústria priorizava.

Essa troca fazia sentido para muito software. Um erro de digitação num botão de uma landing page não precisa de uma inspeção formal de cinco pessoas. Mas a cultura que substituiu as Fagan Inspections trata todo o código da mesma forma, e é aí que o custo se esconde.

Os defeitos mais caros estão no código que parece correto, passa nos testes e falha em produção de formas que custam dinheiro real. Esse é exatamente o código que mais se beneficia de um processo projetado para encontrar defeitos em vez de um processo projetado para aprovar diffs.

A revisão de pull request veio para ficar, e isso está bem. Mas fingir que é um substituto para a inspeção estruturada não está bem. É uma ferramenta diferente para um trabalho diferente, e equipes que possuem apenas uma delas continuarão encontrando bugs caros que um processo melhor teria capturado antes do deploy.

FAQ

O que é uma Fagan Inspection?

Um processo de revisão estruturado e multi-fase para encontrar defeitos em artefatos de software, desenvolvido por Michael Fagan na IBM na década de 1970. Envolve seis fases (Planning, Overview, Preparation, Inspection Meeting, Rework, Follow-up) com papéis específicos para os participantes. A reunião foca exclusivamente em registrar defeitos, não em resolvê-los.

Quão eficazes eram as Fagan Inspections?

A IBM relatou taxas de remoção de defeitos superiores a 90 por cento. Um estudo da NASA em 2002 encontrou que cada hora de inspeção prevenia em média 33 horas de manutenção. Estudos independentes encontraram consistentemente que a inspeção estruturada captura aproximadamente duas vezes mais defeitos que a revisão informal.

Por que as equipes pararam de usar as Fagan Inspections?

O processo consumia de 15 a 20 por cento do esforço total do projeto, exigia agendamento difícil de múltiplos participantes, e era culturalmente rígido. À medida que as equipes de software se moveram para ciclos de release mais rápidos, o overhead se tornou insustentável. A revisão de pull request o substituiu como padrão porque é mais rápida e fácil de integrar ao workflow normal, mesmo que capture menos defeitos.

As equipes modernas ainda podem se beneficiar das Fagan Inspections?

Não na forma original. O processo completo de seis fases com papéis atribuídos não se encaixa no continuous deployment. Mas as ideias centrais — preparation independente, revisão focada time-boxed, registro estruturado de defeitos, e separar a busca por defeitos do design de soluções — podem ser adaptadas. Equipes que aplicam isso seletivamente ao código crítico obtêm grande parte do benefício sem o overhead.