the ninety-ninety rule
expressãoprogramaçãocultura de operações
'Os primeiros 90 por cento do código consomem os primeiros 90 por cento do tempo de desenvolvimento. Os 10 por cento restantes consomem os outros 90 por cento.'
Tom Cargill, do Bell Labs, a cunhou, e a coluna Programming Pearls de Jon Bentley (1985) a canonizou; a aritmética é a piada e a verdade. Demos, caminhos felizes e protótipos são os primeiros 90; casos de borda, integração e acabamento são os segundos. Todo relatório de status 'quase pronto' é a regra em plena execução.
Os primeiros noventa por cento do código tomam noventa por cento do tempo de desenvolvimento, e os dez por cento restantes tomam os outros noventa por cento. A piada de Tom Cargill funciona porque a aritmética é deliberadamente impossível e a experiência é universalmente reconhecida.
O que ela nomeia é a subestimação sistemática da cauda. A funcionalidade demonstrável chega rápido, e então vem tudo que não é demonstrável: tratamento de erros, casos de borda, a história de implantação, a migração dos dados existentes, a interface que precisa funcionar para quem não a construiu, e a longa sequência de pequenos problemas que só aparecem em condições reais. Nada disso é visível num protótipo, e é por isso que protótipos enganam tanto como estimativa.
O uso prático está em como você comunica progresso. Percentual concluído baseado em funcionalidades implementadas é sistematicamente otimista, e um projeto relatado a noventa por cento por vários meses é o formato padrão, e não uma anomalia. Estimar a cauda explicitamente, ou relatar progresso pelo que está genuinamente pronto, incluindo seus modos de falha, é menos satisfatório e consideravelmente mais honesto.