A média da indústria de software na década de 1980 era de 30 a 60 defeitos por mil linhas de código. A equipe Cleanroom da IBM entregou um incremento de compiler de 20.000 linhas com 53 defeitos encontrados em testes. Isso é 2,6 por KLOC. Alguns incrementos individuais de 10.000 linhas foram para teste de sistema sem defeitos encontrados.

A parte mais estranha? Os programadores eram proibidos de executar seu próprio código.

O que Cleanroom software engineering realmente significa

Cleanroom software engineering, desenvolvido pelo matemático Harlan Mills na IBM na década de 1980, é um processo baseado em teoria que se apoia em formal specification, structured design e mathematical correctness verification em vez de Unit Testing e debugging. O nome vem da fabricação de semicondutores. Em uma fábrica de chips, você não introduz poeira para limpá-la depois. Você previne a contaminação desde o início.

Em Cleanroom, os desenvolvedores não fazem Unit Testing. Eles não debugam. Eles verificam.

O processo divide o software em incrementos, tipicamente de 5.000 a 15.000 linhas de código. Cada incremento é especificado, projetado, verificado e então testado estatisticamente como uma unidade completa. Os desenvolvedores escrevem o código, mas não são permitidos compilá-lo ou executá-lo durante o desenvolvimento. A primeira vez que o código executa é durante os testes de sistema formais.

Como box structure verification substitui o debugging

O mecanismo central é a box structure specification. Cada componente é definido em três níveis.

A black box especifica o comportamento externo. Ela define estímulos e respostas sem mencionar o estado interno.

A state box adiciona as variáveis de estado interno e a função de transição de estado.

A clear box é a implementação real, que deve ser um refinamento estruturado da state box.

Essa hierarquia importa porque permite verificar a correção em cada nível independentemente. Você prova que a state box implementa a black box, e que a clear box implementa a state box.

Aqui está como isso parece na prática para uma função com um correctness argument não trivial:

from typing import Optional

def binary_search(arr: list[int], target: int) -> Optional[int]:
    """
    Black box spec:
      Pre:  arr is sorted in non-decreasing order.
      Post: Returns index i such that arr[i] == target,
            or None if target is not present.
    """
    low, high = 0, len(arr) - 1

    while low <= high:
        mid = (low + high) // 2

        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            low = mid + 1
        else:
            high = mid - 1

    return None

O verification argument do loop é o que importa. A equipe revisa isso junta e confirma três fatos. Primeiro, se arr[mid] == target, a postcondition é satisfeita imediatamente. Segundo, se arr[mid] < target, o target só pode existir em indexes maiores que mid, então definir low = mid + 1 preserva o invariante de que o target está em arr[low:high+1] se existir de todo. Terceiro, se arr[mid] > target, o argumento simétrico vale para high = mid - 1.

Isso não é um Code Review onde alguém pergunta se você pensou em arrays vazios. Isso é uma prova de grupo estruturada de que cada entrada possível produz a saída especificada.

Os números da IBM por trás da afirmação de zero defeitos

A IBM aplicou Cleanroom em três projetos importantes no final da década de 1980 e início de 1990: a COBOL Structuring Facility (40.000 linhas), um programa de voo de helicóptero da Força Aérea (35.000 linhas) e um sistema de planejamento de transporte espacial da NASA (45.000 linhas).

Os dados da COBOL/SF são os mais detalhados. O primeiro incremento de 20.000 linhas foi desenvolvido com formal specifications, box structure design e correctness verification em grupo. Os desenvolvedores não tinham permissão para compilar ou executar seus modules durante o desenvolvimento. O código foi direto para o teste de sistema.

Resultado: 53 defeitos encontrados durante os testes. Mais de 90% de todos os defeitos foram capturados durante a fase de verificação antes do código ser executado.

Para comparação, projetos convencionais da IBM na época encontravam cerca de 60% dos defeitos antes da execução. Cleanroom inverteu a proporção.

Alguns incrementos, particularmente os menores de menos de 10.000 linhas, relataram zero defeitos encontrados em teste de sistema. É daqui que vem a afirmação de “10.000 linhas com zero defeitos”. Aconteceu. Não foi universal, mas foi reproduzível o suficiente para que a IBM o transformasse em um benchmark padrão.

Por que não executar seu próprio código produz menos bugs

Esta é a parte que quebra a cabeça dos desenvolvedores. Como não testar pode produzir código melhor?

A resposta é cognitiva, não técnica. Quando você sabe que não pode executar o código para verificar seu trabalho, você projeta com mais cuidado. Você escreve funções menores. Você pensa em Edge Cases antes de digitar. Você se apoia no Type System e na programação estruturada porque não tem rede de segurança.

É o mesmo motivo pelo qual cirurgiões usam checklists. A restrição força um modo mental diferente.

Há também uma camada de controle de qualidade estatística. Cleanroom usa statistical usage testing baseado em um operational profile. Casos de teste são extraídos da distribuição de probabilidade do comportamento real do usuário, não da suposição do desenvolvedor sobre onde estão os bugs. Isso significa que você está medindo confiabilidade, não apenas caçando bugs.

Os trade-offs que mantiveram Cleanroom em nicho

Cleanroom não conquistou o mundo. Há razões.

Primeiro, a barreira de treinamento é severa. Você precisa de equipes que possam escrever formal specifications e construir mathematical correctness arguments. A maioria dos graduados em CS em 2025 nunca fez uma prova formal de uma função não trivial.

Segundo, o custo de design inicial é alto. A IBM relatou que o texto de specification excedeu o texto de design por quatro a um no projeto COBOL/SF. Você está trocando tempo de design por tempo de teste. Isso funciona para compilers e software de voo. Não funciona para um aplicativo CRUD com requisitos de pivot semanais.

Terceiro, a afirmação de zero defeitos é sobre defect density, não sobre a ausência de todos os bugs. Um incremento Cleanroom ainda pode ter specification errors. Se a black box está errada, a clear box verificada também está errada, apenas por construção.

Como roubar a disciplina Cleanroom sem a burocracia

Você provavelmente não pode adotar Cleanroom completo. Seu Gerente de Produto não esperará uma razão de especificação para código de quatro para um. Mas você pode roubar as peças de maior valor.

1. Escreva o contract antes da implementação.

Use preconditions, postconditions e invariants para definir sua black box. Mesmo comentários informais forçam você a pensar sobre limites antes de otimizar.

from typing import List, Tuple

def partition(nums: List[int], pivot: int) -> Tuple[List[int], List[int]]:
    """
    Black box spec:
      Pre:  True (any list of integers is valid).
      Post: left contains exactly the elements of nums where x <= pivot.
            right contains exactly the elements of nums where x > pivot.
            len(left) + len(right) == len(nums).
    """
    left = [x for x in nums if x <= pivot]
    right = [x for x in nums if x > pivot]

    # Runtime checks act as lightweight verification witnesses.
    assert all(x <= pivot for x in left)
    assert all(x > pivot for x in right)
    assert len(left) + len(right) == len(nums)

    return left, right

2. Substitua alguns Unit Tests por verification arguments.

Antes de escrever o teste, escreva um argumento de uma frase sobre por que o código está correto. Se você não conseguir construir essa frase, o design é muito complexo. Esta é a prática Cleanroom mais eficaz para equipes modernas.

3. Use property-based testing como statistical usage testing.

Ferramentas como Hypothesis em Python ou fast-check em JavaScript geram entradas a partir de uma distribuição. Isso é espiritualmente mais próximo do statistical testing de Cleanroom do que Unit Tests baseados em exemplos.

4. Separe compilação de verificação.

Se você habitualmente escreve uma linha, compila, corrige o erro de digitação, escreve outra linha, você está debugando por reflexo de espasmo. Tente escrever uma unidade lógica completa antes de executá-la. O desconforto é o ponto.

FAQ

Cleanroom ainda é usado hoje?

Sobrevive em domínios de segurança crítica e missão crítica. A NASA, a FAA e alguns fabricantes de dispositivos médicos usam variantes do processo. É raro em software comercial.

Posso realmente entregar código sem Unit Testing?

Apenas se você o substituir por algo igualmente rigoroso. As equipes Cleanroom passaram mais horas em verificação do que a maioria das equipes em testing. O tempo não desapareceu. Foi movido para a esquerda.

Cleanroom garante zero bugs?

Não. Garante que a implementação corresponde à specification com alta probabilidade. Se a specification está errada, o bug é preservado perfeitamente.

Qual foi o impacto na produtividade?

A IBM relatou uma produtividade de mais de 400 linhas de código por pessoa-mês no projeto COBOL/SF, em grande parte porque o tempo de teste drasticamente reduzido compensou o esforço de design aumentado.

Conclusão

Da próxima vez que alguém afirmar que uma metodologia entrega software zero-defect, peça os dados do projeto. Os números de Cleanroom da IBM são reais, mas vieram de um contexto específico: equipes experientes, treinamento formal, entrega incremental e a disposição de verificar em vez de debugar.

O incremento de 10.000 linhas com zero defeitos é alcançável. Apenas custa mais previsão do que a maioria das organizações está disposta a pagar.