A lei de Brooks precifica coordenação, e a IA levou a conta para a revisão de código

No capítulo 2 de The Mythical Man-Month, publicado pela Addison-Wesley em 1975, Frederick Brooks faz uma conta que vale refazer. Uma tarefa é estimada em 12 pessoas-mês e entregue a três pessoas por quatro meses, com um ponto de controle ao fim de cada mês. O primeiro ponto de controle só é alcançado depois de dois meses. O reflexo gerencial de sempre é acrescentar gente, então suponha que duas pessoas entrem. Brooks contou quanto isso custa. Se uma pessoa experiente gasta um mês treinando os recém-chegados, esse mês somado ao mês dos próprios novatos dá três pessoas-mês consumidas em trabalho que não estava na estimativa. A tarefa que estava dividida em três agora precisa ser dividida em cinco, e parte do que já estava pronto se perde na nova repartição. Ao fim do terceiro mês, escreveu ele, restam bem mais de sete pessoas-mês de trabalho, e cinco pessoas treinadas têm um mês para fazê-lo. O projeto está atrasado de novo, agora com cinco pessoas, e repetir a manobra, acrescentou, é onde mora a loucura.

O resumo de uma linha, de que pôr mais gente num projeto de software atrasado só o atrasa mais, é citado há cinquenta anos como se fosse uma proibição. Acho essa leitura errada, e o próprio Brooks trouxe a correção na frase que apresenta a lei, que começa com "Oversimplifying outrageously" (simplificando de modo escandaloso, em tradução livre). A conta detalha uma fatura com duas linhas, a adaptação e a comunicação, e enumera as condições em que essa fatura continua pequena. Quem lê a lei como "nunca contrate" vai recusar uma contratação que se pagaria sozinha. Quem a ignora continua pagando uma conta que ninguém detalhou.

Meu argumento tem três partes. Primeiro, a fórmula n(n-1)/2 que todo mundo lembra conta pares possíveis. A fatura depende de quantos desses pares estão ativos e do que cada um custa. Segundo, a geração de código por IA reduz o custo de escrever e deixa o custo por canal onde estava, ou o eleva, porque o canal mais movimentado de um time moderno agora passa por quem lê as mudanças. A coordenação não desapareceu; mudou-se para a revisão e a integração. Terceiro, e esta é a parte que uma pessoa razoável pode contestar, o tamanho de time que termina um trabalho mais depressa diminui à medida que escrever fica mais barato em relação a revisar. Testo essa última afirmação com um modelo de brinquedo cujos números inventei e com a telemetria que existe. A telemetria é em sua maior parte dado de fornecedor, e pende para um lado sem resolver a questão.

A lei precifica dois custos e diz em que caso nenhum deles se aplica

Brooks parte do homem-mês como unidade de trabalho e argumenta que ela esconde uma suposição, a de que pessoas e meses se trocam de modo uniforme. Só se trocam quando a tarefa pode ser repartida entre muitos trabalhadores sem comunicação entre eles, e seus exemplos são a colheita de trigo e de algodão. Quando a tarefa não pode ser repartida por causa de restrições sequenciais, gente extra não adianta nada para o cronograma, e ele diz que muitas tarefas de software são assim, porque depurar é sequencial. No meio fica o caso que importa: tarefas que podem ser repartidas, mas cujas partes precisam conversar entre si. Ali o esforço adicional tem dois componentes. O treinamento é linear no número de pessoas, já que cada recém-chegado precisa aprender a tecnologia, os objetivos, a estratégia e o plano. A intercomunicação cresce como n(n-1)/2, de modo que três trabalhadores exigem três vezes a comunicação par a par de dois, e quatro exigem seis vezes. Se o trabalho ainda pede reuniões de três ou mais pessoas para decidir as coisas, diz ele, a situação piora.

Dois limites do mesmo texto são citados com menos frequência que a lei. O número de meses que um projeto leva depende de suas restrições sequenciais, e o número máximo de pessoas úteis depende do número de subtarefas independentes. A equipe também não pode crescer em qualquer velocidade: nas notas ao capítulo, Brooks cita V. A. Vyssotsky, dos Bell Telephone Laboratories, que estimou que um projeto grande sustenta uma expansão de 30 por cento ao ano, e que mais que isso força a estrutura informal pela qual as pessoas se encontram. Os dois limites dependem do formato do trabalho, seja qual for o número de pessoas.

Pesquisadores posteriores transformaram a ideia numa fórmula. Di Penta, Harman, Antoniol e Qureshi (2007) escreveram o tempo de conclusão como t = e/n + ce × n(n-1)/2, em que e é o esforço total, n é o tamanho do time e ce é o esforço médio para um par coordenar. Para uma tarefa perfeitamente divisível, o segundo termo some e a lei de Brooks não se aplica. Para uma tarefa indivisível, nada ajuda. Entre os dois extremos a curva tem um mínimo, e depois dele cada pessoa acrescentada alonga o cronograma. A análise que fizeram de dois projetos reais de manutenção os levou a concluir que o efeito é sutil e pode ser menos nocivo quando a formação do time é flexível. O único parâmetro de coordenação, ce, é o que torna o modelo útil, porque transforma a lei numa pergunta sobre em que ponto da curva o time está.

Pares possíveis não são canais ativos, e a diferença é decisão de projeto

A contagem de pares cresce rápido. Seis pessoas têm 15 pares possíveis, dez têm 45 e quinze têm 105. Numa entrevista de 2009 à Harvard Business Review, com Diane Coutu, J. Richard Hackman disse que ele e um colega haviam encontrado os vínculos entre os membros crescendo a uma taxa acelerada, quase exponencial, que sua regra prática é "no double digits" (nada de dois dígitos) e que em seus cursos nunca permite times com mais de seis alunos. A contagem de pares cresce de forma quadrática, então "exponencial" foi uma palavra solta numa entrevista falada. O Scrum Guide de 2020 fixa o tamanho de um time Scrum em tipicamente dez pessoas ou menos e afirma que times menores se comunicam melhor e são mais produtivos, uma afirmação que o guia faz sem dados nem citação.

Essas são regras práticas construídas sobre a contagem de pares possíveis. A contagem tem a ordem de grandeza certa para um grupo em que todos precisam saber o que todos os outros estão fazendo e o número errado para quase qualquer outro grupo. Os 2.134 desenvolvedores que contribuíram em um único ciclo de lançamento do kernel Linux, discutido adiante, formam cerca de 2,3 milhões de pares possíveis, e ninguém diria que o kernel funciona com 2,3 milhões de canais. Melvin Conway fez a observação de fundo em 1968, em "How Do Committees Invent?". Ele notou que os caminhos possíveis entre pessoas crescem como cerca de metade do quadrado do seu número, concluiu que as organizações precisam restringir a comunicação e observou que essas restrições são copiadas para a estrutura dos sistemas que elas projetam. A contagem, portanto, é uma variável de projeto. Um time escolhe quais canais ficam abertos e constrói interfaces para que os demais possam ficar fechados.

A contagem de pares também é uma fatura imperfeita nos dois sentidos. O próprio Brooks observa que reuniões de três ou mais pioram as coisas além do que os pares fariam. E a coordenação não é a única fonte de perda num grupo: nos experimentos de cabo de guerra de Ingham, Levinger, Graves e Peckham (1974), o esforço por pessoa caiu à medida que os grupos cresciam. Segundo os resumos secundários do desenho do estudo, a queda apareceu também em pseudogrupos, nos quais o participante acreditava que outros puxavam a corda a seu lado mas puxava sozinho, de modo que a má coordenação não pode ser a explicação inteira. Não li o artigo completo, e puxar uma corda está bem longe de escrever software. Ainda assim, o resultado sugere que um modelo que conta só coordenação subestima o que um grupo grande custa, enquanto para trabalho modular a contagem de pares superestima os canais que importam. A fatura verdadeira fica em algum ponto entre as duas.

A telemetria mostra indivíduos mais rápidos e a fila atrás deles crescendo

A Faros AI, fornecedora de análise de engenharia, publicou um estudo datado de 23 de julho de 2025 (a nota metodológica diz que a análise reflete dados até junho de 2025), baseado em telemetria de mais de 10.000 desenvolvedores em 1.255 times. O estudo relatou que desenvolvedores de times com alta adoção de IA concluíram 21% mais tarefas e integraram 98% mais pull requests, enquanto o tempo de revisão de pull request subiu 91%, o tamanho médio do pull request subiu 154% e os bugs por desenvolvedor subiram 9%. Não encontrou correlação significativa entre adoção de IA e melhora no nível da empresa. O método foi a correlação de postos de Spearman sobre métricas padronizadas dentro de cada empresa, com até dois anos de dados trimestrais, e as variações por time comparam os dois trimestres de menor adoção de cada time com os dois de maior adoção. Os resultados são, portanto, associações, e uma empresa que vende medição escolheu o que medir. A página que li nunca define tempo de revisão e não diz se ele significa a espera em relógio por pull request ou o total de horas que os revisores gastam. A diferença importa, porque uma espera crescente aponta para uma fila e horas crescentes apontam para esforço.

Em 2026 a Faros publicou um relatório sobre 22.000 desenvolvedores em 4.000 times. Uma página do site da Faros que o cita diz que os épicos concluídos por desenvolvedor subiram 66% entre o período de menor e o de maior adoção de IA de cada organização, que os bugs por desenvolvedor subiram 54% e que a probabilidade de um incidente em produção por pull request integrado mais que triplicou. Não vi o relatório em si, então trato esses números como alegações de um fornecedor. Eles apontam na mesma direção do primeiro estudo.

Fontes com outro desenho concordam quanto à direção e divergem quanto ao tamanho. O DORA, programa de pesquisa do Google, relatou em 2024 que um aumento de 25% na adoção de IA estava associado a uma queda estimada de 1,5% na vazão de entrega e de 7,2% na estabilidade da entrega, junto com um aumento de 3,1% na velocidade de revisão de código relatada. Os autores escreveram que o resultado contrariava suas expectativas e ofereceram uma hipótese: como a IA permite produzir muito mais código no mesmo tempo, as listas de mudanças provavelmente estão crescendo, e o DORA constata há anos que mudanças maiores são mais lentas e mais propensas à instabilidade. Em 2025, a partir de uma pesquisa com quase 5.000 profissionais, o DORA relatou que a adoção de IA agora melhora a vazão de entrega mas ainda aumenta a instabilidade, e levantou a hipótese de que a instabilidade se deve, provavelmente em parte, ao fato de lotes maiores de código serem mais difíceis de revisar. Constatou também, com o que chamou de alto grau de certeza, que times que trabalham em lotes pequenos veem amplificado o efeito positivo da IA sobre o desempenho do produto. As duas explicações são leituras que os autores fazem de modelos de pesquisa por questionário. Nenhuma é uma medição de revisão. Um artigo do DORA de março de 2026, "Balancing AI tensions", vai mais longe nas palavras: diz que os ganhos de velocidade dos autores podem se traduzir num aumento significativo da carga cognitiva de quem revisa, e cita lotes pequenos como contramedida. Soa como comentário dos pesquisadores do DORA, e não vi uma medição de revisão na página que abri.

O ensaio randomizado mais conhecido é pequeno e já datado. O METR (Becker, Rush, Barnes e Rein, 2025) atribuiu 246 tarefas de repositórios maduros de código aberto a 16 desenvolvedores experientes, com ferramentas de IA permitidas ou proibidas por sorteio, e constatou que permitir a IA aumentou o tempo de conclusão em 19%. Os desenvolvedores tinham previsto uma redução de 24% no tempo e, depois, acreditaram ter ganhado 20%. Eram ferramentas do início de 2025, então o resultado diz pouco sobre as de hoje. A própria atualização do METR de fevereiro de 2026, sobre um acompanhamento maior iniciado no fim de 2025, chamou seus dados de sinal pouco confiável do efeito atual, sobretudo porque desenvolvedores que esperavam grandes ganhos recusavam cada vez mais trabalhar sem IA, e o METR disse acreditar que os desenvolvedores estão provavelmente mais acelerados agora do que no início de 2025, ao mesmo tempo em que classificou como muito fraca a evidência de quanto. O que sobrevive do ensaio de 2025 é a distância que pode haver entre a velocidade sentida e a medida. É um motivo para medir a fila diretamente, em vez de perguntar às pessoas quão rápido as coisas parecem.

Para o tamanho da fila, o melhor ponto de referência público é mais antigo. Sadowski e colegas estudaram a revisão de código no Google num artigo de 2018, abrangendo cerca de 9 milhões de mudanças revisadas entre janeiro de 2014 e julho de 2016. O desenvolvedor mediano era autor de cerca de 3 mudanças por semana, revisava 4 e gastava uma mediana de 2,6 horas por semana revisando. A mudança mediana tocava 24 linhas, o primeiro retorno sobre mudanças pequenas vinha em menos de uma hora na mediana, e a latência mediana da revisão inteira ficava abaixo de quatro horas. Agora aplique como aritmética os números de alta adoção da Faros. Se os pull requests integrados de um time quase dobram e cada um fica duas vezes e meia maior, as linhas que cada revisor precisa ler crescem cerca de cinco vezes (1,98 × 2,54 dá aproximadamente 5), a menos que os revisores leiam com menos cuidado. Estou multiplicando duas médias que a Faros relata separadamente, então o resultado dá uma ordem de grandeza e nada mais firme. As poucas horas por semana que os revisores têm precisam se esticar, ou a fila cresce, e uma fila é custo de coordenação em sua forma mais simples: trabalho esperando pela atenção de uma pessoa.

Um modelo de brinquedo: escrever mais barato e revisar mais caro encolhem o melhor time

Tome a forma de Di Penta e ponha números nela, com o aviso de que todo número aqui é inventado para ilustrar. Uma funcionalidade exige 120 pessoas-dia quando uma pessoa a faz. Cada par de pessoas perde meio dia coordenando, então dias para terminar = 120/n + 0,5 × n(n-1)/2. Agora dois cenários para a IA. No cenário B, a geração de código reduz o esforço pela metade, para 60 pessoas-dia, e deixa o custo por par como está. No cenário C o esforço também cai pela metade, mas o custo por par dobra para um dia inteiro, como representação de uma produção que chega em mudanças maiores, que dão mais trabalho de revisão e integração. Dias para terminar, por tamanho de time:

Tamanho do time	Base	B: esforço pela metade	C: esforço pela metade, custo por par dobrado
1	120	60	60
3	41,5	21,5	23
4	33	18	21
5	29	17	22
6	27,5	17,5	25
8	29	21,5	35,5
10	34,5	28,5	51

A base é mais rápida com seis pessoas. Em B o melhor tamanho é cinco. Em C é quatro, e um time de dez, com 51 dias, ganha de uma pessoa trabalhando sozinha, com 60, por apenas nove dias. O custo de escrever caiu pela metade nos dois cenários, e em C o melhor time ainda termina em 21 dias contra 27,5, então a IA ajuda. O que muda é quantas pessoas se podem acrescentar antes que passem a custar tempo, e a resposta cai de seis para quatro. O modelo também diz o que medir. Seu parâmetro ce é o custo médio de um canal ativo, e num time que gera código com IA a maior parte dele é tempo na fila de revisão.

O brinquedo ignora treinamento, limites sequenciais e o fato de que a carga de revisão cresce com o volume de mudança e não com o número de pares. Ele mostra uma direção e nada diz sobre magnitude. A hipótese do cenário C, de que o custo por par dobra, é o elo mais fraco, e os dados da Faros e do DORA são a única razão pela qual acho que ela aponta para o lado certo.

Times grandes funcionam, e os que funcionam são árvores de times pequenos

A objeção mais forte é que grupos grandes claramente dão certo. O Linux é o exemplo-padrão. No ciclo 6.18, encerrado no fim de 2025, Jonathan Corbet, do LWN, contou 13.710 commits de 2.134 desenvolvedores, o maior número de desenvolvedores da história do kernel. Se os custos de coordenação punissem grupos grandes, isso seria impossível, e grandes organizações de produto com centenas de engenheiros acrescentam mais evidência. Se uma arquitetura modular isola o trabalho, segue a objeção, a IA muda pouco, já que cada time simplesmente gera mais rápido dentro do seu módulo.

Aceito a maior parte disso, e a evidência sobre como esses grupos funcionam sustenta a leitura estrutural. Mockus, Fielding e Herbsleb (2002) estudaram o Apache e o Mozilla. No Apache, quase 400 pessoas contribuíram com código, e os 15 desenvolvedores mais ativos responderam por mais de 83% das mudanças e 88% das linhas acrescentadas. Os autores levantaram a hipótese de que um núcleo que se coordena de modo informal fica entre 10 e 15 pessoas e de que um projeto que precisa de mais tem de acrescentar processo explícito, propriedade de código ou inspeções obrigatórias; o Mozilla, cujos núcleos de módulo iam de 22 a 36 pessoas, confirmou isso. Lá, os patches passavam primeiro pelos donos de módulo e depois por um grupo menor de superrevisores, e em metade dos relatos de bug corrigidos, 43% ou mais do tempo de resolução ficava entre a correção e sua verificação, o que levou os autores a dizer que a inspeção obrigatória quase dobrou o intervalo de resolução. O Linux tem o mesmo formato. No 6.18, 53,6% dos commits traziam uma etiqueta Reviewed-by, e Corbet relata que pouco mais da metade dos patches da linha principal passa por mantenedores de cinco empresas.

Os grandes times que funcionam são árvores de pequenos. Grupos pequenos são donos de uma área, e há uma etapa de revisão em cada fronteira. A contagem de pares que importa é o tamanho do grupo que compartilha uma área de código, que é onde a fórmula de Brooks se aplica, e a fila de revisão é o canal entre os grupos. Nada nesses exemplos refuta a lei. Eles coincidem com o limite de Brooks de que o número útil de pessoas é limitado pelo número de subtarefas independentes, com a arquitetura e o processo de revisão tornando as subtarefas independentes.

A objeção ainda tem força em um aspecto: um sistema bem modular consegue absorver gente, e Brooks diz isso. Mas essa modularidade é paga antes de o projeto atrasar, em interfaces, responsáveis e regras de inspeção, e um projeto atrasado costuma ser aquele em que a decomposição não se sustentou, razão pela qual pôr gente nele falha. Os exemplos mostram também que o tempo de revisores e mantenedores é o insumo escasso em escala. Se a IA aumenta a oferta de patches sem aumentar a oferta de atenção de revisores, as fronteiras da árvore são o lugar onde o volume extra vai esperar. Esse último passo é inferência minha a partir do padrão, e ninguém o mediu.

Antes de pôr mais gente num projeto atrasado, ache as interfaces e meça a fila de revisão

Divida ao longo das interfaces antes de acrescentar alguém. Conte primeiro as subtarefas independentes, como o limite de Brooks implica, e dê a cada uma um responsável e uma interface que possa ser testada sem o resto. Se você não consegue nomear a interface, a pessoa nova entra no pool compartilhado, e o pool compartilhado é onde a fatura se acumula. A observação de Conway ajuda, já que as fronteiras dos times viram as costuras do sistema; trace-as onde você quer as costuras.

Acrescente gente cedo, se for o caso. Os próprios números de Brooks mostram por quê. No exemplo dele, os dois recém-chegados não produzem nada no terceiro mês enquanto o instrutor perde um mês, e no quarto mês entregam duas pessoas-mês, de modo que no melhor caso rendem uma pessoa-mês líquida antes da repartição e do teste extra de sistema que ele também contou. Se os mesmos dois tivessem entrado no início do projeto de quatro meses, a mesma aritmética dá seis pessoas-mês de trabalho produtivo contra a perda de um mês do instrutor. É um recálculo meu a partir do cenário dele, e ele não declara esse número. O custo de treinamento é o mesmo quando quer que as pessoas entrem, mas o cronograma que sobra para pagá-lo encolhe a cada semana. Quando sobra pouco cronograma, Brooks lista as alternativas: reprogramar uma vez e com folga, ou reduzir a tarefa.

Mantenha pequeno o grupo que compartilha uma fila de revisão. O seis de Hackman e o dez do Scrum Guide são limites superiores tirados da experiência. O modelo de brinquedo diz que o número certo cai quando a revisão é o canal caro, e os achados do DORA favorecem lotes pequenos. Mudanças pequenas são também a alavanca mais barata, e o estudo do Google observa que seus tempos curtos de revisão podem dever algo ao tamanho pequeno das mudanças.

Meça a fila de revisão, já que é ali que o modelo põe o custo. Cinco números bastam para começar:

1. Mediana e percentil 90 do tempo entre abrir um pull request e sua primeira revisão humana.
2. Mediana e percentil 90 de linhas alteradas por pull request, comparadas a uma referência de antes da chegada das ferramentas de IA.
3. Pull requests criados e pull requests revisados por pessoa por semana, para que uma distância crescente mostre para onde a atenção está indo.
4. Horas por semana que cada pessoa gasta revisando, tiradas dos dados da ferramenta.
5. Taxa de falha de mudanças e taxa de retrabalho, as duas medidas de instabilidade do relatório DORA de 2025, lidas junto com as quatro primeiras.

Um primeiro passo concreto é puxar os pull requests integrados dos últimos dois trimestres e calcular os três primeiros números por time. Se a mediana de espera pela primeira revisão cresceu no ritmo dos pull requests por autor, o time já está do lado direito da curva do modelo, e a próxima contratação deve ser questionada antes de ser feita. Se a revisão assistida por IA achata essa fila ou cria uma segunda, que alguém terá de supervisionar, é uma pergunta que não consigo resolver. Os dados que encontrei medem a autoria muito melhor do que medem a revisão.

Fontes

1. Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering, capítulo 2, "The Mythical Man-Month". Addison-Wesley. Texto do capítulo lido em PDF de leitura hospedado pela Duke University (courses.cs.duke.edu/compsci408/fall16/readings/mythical_man_month.pdf); a nota sobre Vyssotsky foi lida no texto da edição de aniversário de 1995 no Internet Archive.
2. Di Penta, M., Harman, M., Antoniol, G., Qureshi, F. (2007). The Effect of Communication Overhead on Software Maintenance Project Staffing: a Search-Based Approach. IEEE International Conference on Software Maintenance (ICSM 2007), Paris. Lido em cópia hospedada em www2.csc.liv.ac.uk (página de disciplina da University of Liverpool).
3. Coutu, D. (maio de 2009). Why Teams Don't Work (entrevista com J. Richard Hackman). Harvard Business Review. hbr.org/2009/05/why-teams-dont-work.
4. Schwaber, K., Sutherland, J. (novembro de 2020). The Scrum Guide. scrumguides.org.
5. Conway, M. E. (abril de 1968). How Do Committees Invent? Datamation 14(4), 28-31. melconway.com/Home/Committees_Paper.html.
6. Ingham, A. G., Levinger, G., Graves, J., Peckham, V. (1974). The Ringelmann effect: Studies of group size and group performance. Journal of Experimental Social Psychology 10(4), 371-384. Descrito aqui apenas a partir de resumos secundários; o artigo completo não foi lido.
7. Faros AI (23 de julho de 2025). The AI Productivity Paradox Report 2025. faros.ai/blog/ai-software-engineering. Relatório de fornecedor baseado em telemetria.
8. Faros AI (2026). AI Engineering Report 2026, com números conforme citados em faros.ai/comparison/github-copilot-vs-codeium e escopo conforme declarado em faros.ai/research. O relatório em si não foi lido.
9. DORA, Google Cloud (2024). Accelerate State of DevOps Report 2024, seção "Exploring the downstream impact of AI". services.google.com/fh/files/misc/2024_final_dora_report.pdf.
10. DORA, Google Cloud (2025). State of AI-assisted Software Development, sumário executivo e capítulo do modelo de capacidades de IA. services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf. Também DORA (10 de março de 2026), Balancing AI tensions: Moving from AI adoption to effective SDLC use, dora.dev/insights/balancing-ai-tensions/.
11. Becker, J., Rush, N., Barnes, E., Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. Também METR (fevereiro de 2026), atualização sobre seu experimento de produtividade de desenvolvedores do fim de 2025, metr.org/blog/2026-02-24-uplift-update/.
12. Sadowski, C., Soderberg, E., Church, L., Sipko, M., Bacchelli, A. (2018). Modern Code Review: A Case Study at Google. ICSE-SEIP 2018, doi.org/10.1145/3183519.3183525.
13. Mockus, A., Fielding, R. T., Herbsleb, J. D. (2002). Two case studies of open source software development: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology 11(3). Números lidos no rascunho pré-publicação do autor em mockus.org/papers/mozilla.pdf.
14. Corbet, J. (1 de dezembro de 2025). Some 6.18 development statistics. LWN.net, lwn.net/Articles/1046966.
15. Modelo ilustrativo de tempo de time: 120 pessoas-dia de esforço, meio dia por par (um dia no cenário C), esforço reduzido à metade nos cenários B e C, conforme declarado no texto. Os parâmetros são inventados; apenas a forma funcional vem do item 2.
16. Aritmética ilustrativa: o recálculo do exemplo de quatro meses de Brooks e o produto 1,98 × 2,54 de duas médias da Faros relatadas separadamente, conforme declarado no texto.