O programa como teoria

Imagine que toda a sua equipe sênior ganha na loteria amanhã e some.

O código continua lá. Compila, sobe em produção, atende clientes. Mas, na primeira mudança de requisito não-trivial, ninguém consegue tocá-lo sem medo de quebrar três coisas que não entende.

O programa não morreu por falta de código. Morreu por falta de uma coisa que nunca esteve no repositório.

A tese de Peter Naur é que essa coisa é o produto de verdade da programação.

Programar não é produzir texto (código). É construir uma teoria — um conhecimento em grande parte tácito que vive na mente de quem desenvolve, não no artefato.

TL;DR

Em Programming as Theory Building (1985), Peter Naur argumenta que o produto real da programação não é o código, mas a teoria que os desenvolvedores formam: como o programa corresponde ao mundo, por que está estruturado assim, e como evoluí-lo de forma coerente. Código e documentação são externalizações parciais dessa teoria. Quando a equipe que a detém se dispersa, o programa “morre” — ainda compila, mas ninguém consegue modificá-lo com segurança. Reviver não é ler a documentação: é reconstruir a teoria, trabalho lento e humano. É a base teórica do débito cognitivo.

O que é: programar é construir uma teoria

Vale saber de onde vem a tese. Peter Naur (1928–2016) foi um cientista da computação dinamarquês — editor do relatório do ALGOL 60, vencedor do Prêmio Turing (2005) e defensor incansável da datalogy: o estudo dos dados e da prática humana, não só da máquina.

Não é, portanto, um romântico anti-técnico. É alguém do coração da computação formal dizendo que a parte que mais importa não é formalizável por inteiro.

Naur escreveu o ensaio em 1985 contra uma ideia dominante. A ideia de que programar é, no fundo, fabricar um artefato — o código — e que a documentação seria o registro fiel desse artefato.

A tese central inverte isso: programar é construir uma teoria, não produzir texto.

O que ele chama de “teoria” não é um documento nem um conjunto de fórmulas. É a compreensão viva que a equipe forma sobre o sistema:

• como ele se comporta;
• por que tem a forma que tem;
• como mudá-lo sem que se desfaça.

O código-fonte e a documentação são, no máximo, externalizações parciais dessa teoria. São registros com perda (lossy).

A teoria de verdade mora na cabeça dos programadores.

Repare na consequência imediata. Se o ativo é a teoria, então o que importa preservar não é só o repositório — é a mente que sabe lê-lo.

Knowing-that vs. knowing-how: a teoria no sentido de Ryle

Naur empresta o conceito de “teoria” do filósofo Gilbert Ryle (The Concept of Mind, 1949).

Ryle separa dois tipos de conhecimento:

• Knowing-that (saber proposicional) — saber que algo é o caso. Fatos, regras, enunciados. Cabe num texto: “a função calcularJuros usa juros compostos”.
• Knowing-how (saber-fazer) — uma capacidade. Saber andar de bicicleta, diagnosticar um bug, julgar se uma mudança “encaixa” no design. Não se reduz a uma lista de proposições.

Ter uma “teoria” de algo, no sentido de Ryle, é do segundo tipo: é a capacidade de explicar, justificar e responder a situações novas — não a posse de um texto.

Um exemplo de software deixa a distinção concreta. Você pode memorizar (saber-que):

• “este serviço publica eventos numa fila quando um pedido é criado”.

Mas a teoria é saber-como:

• prever o que vai quebrar se você trocar a fila por chamada síncrona;
• farejar que aquele try/catch silencioso esconde um caso de borda real;
• julgar, diante de uma feature nova, se ela cabe no design ou o trai.

O primeiro item cabe num wiki. Os outros três são uma capacidade que se forma fazendo — e que some quando a pessoa que a tinha vai embora.

Ryle, sobre o erro intelectualista

Ryle ataca o que chama de intellectualist legend: a ideia de que toda ação inteligente vem de primeiro consultar uma regra (proposição) na mente e depois executá-la.

O argumento da regressão: se agir com inteligência exigisse antes pensar numa regra, então pensar nessa regra com inteligência exigiria consultar outra regra antes — e assim ao infinito. A inteligência, conclui Ryle, se manifesta na própria ação, não num passo anterior a ela.

Por que isso importa para software? Porque mostra que o “saber programar este sistema” é irredutível a qualquer manual. Não é um texto que faltou escrever; é uma capacidade que se forma fazendo.

flowchart LR
    subgraph KT["Knowing-that (proposicional)"]
        direction TB
        A["Fatos e regras"] --> B["Cabe em texto"]
        B --> C["Transferível por leitura"]
    end
    subgraph KH["Knowing-how (capacidade)"]
        direction TB
        D["Habilidade / julgamento"] --> E["Resiste à escrita completa"]
        E --> F["Transferível só pela prática"]
    end
    KT -. "a teoria do programa NÃO é isto" .-> KH
    KH --> G["A teoria de Naur vive aqui"]

Leitura do diagrama: a documentação consegue capturar o lado esquerdo (knowing-that), mas a teoria do programa é uma capacidade — o lado direito —, e é por isso que ler tudo não basta.

Por que a teoria não cabe na documentação

A teoria é majoritariamente tácita.

Aqui entra Michael Polanyi (The Tacit Dimension, 1966) e seu lema célebre: “sabemos mais do que conseguimos dizer” (we can know more than we can tell).

O ponto de Polanyi é que há sempre uma camada de conhecimento que opera por baixo da fala — e que nem mesmo um especialista honesto consegue verbalizar por inteiro, por mais que tente.

Isso é o que hoje se chama paradoxo de Polanyi: tarefas que executamos com fluência intuitiva, mas cujas regras não sabemos enunciar.

Aplicado ao código, o resultado é direto.

A documentação e o código conseguem registrar parte do “o quê”:

• o quê o sistema faz;
• quais são as entidades, as rotas, os contratos.

Mas o “porquê” e a capacidade de julgar mudanças coerentes resistem à externalização completa:

• por que esta fila existe em vez de uma chamada síncrona?
• por que este caso de borda esquisito está tratado assim — que bug de produção ele cicatriza?
• esta nova feature encaixa no design ou o trai?

Por que isso acontece?

Polanyi explica com uma distinção fina. Em todo saber-fazer há uma estrutura “de-para” (from-to):

• estamos focalmente atentos ao todo — andar de bicicleta, ler o sistema;
• e nos apoiamos subsidiariamente em mil particulares que não olhamos diretamente — o equilíbrio, os reflexos, o “cheiro” de uma parte do código.

O detalhe cruel: se você vira a atenção para os particulares subsidiários, a performance se desfaz. Foque nos dedos enquanto digita e você trava.

É por isso que pedir ao sênior “escreva tudo o que você sabe sobre este sistema” não funciona.

Boa parte do que ele sabe só opera enquanto permanece subsidiário — vira inútil no instante em que é forçado a virar texto.

Por melhor que seja a documentação, ela nunca transmite a teoria por inteiro. Ela ajuda quem já está reconstruindo a teoria — serve de andaime —, mas não a substitui.

flowchart TD
    T["A TEORIA<br/>(na mente da equipe — completa)"]
    T --> C["Código-fonte<br/>(o 'o quê', estruturas, contratos)"]
    T --> D["Documentação / ADRs<br/>(parte do 'porquê')"]
    T -.->|"não captura"| L1["Por que ESTA estrutura<br/>e não outra"]
    T -.->|"não captura"| L2["Casos de borda<br/>e suas cicatrizes"]
    T -.->|"não captura"| L3["Julgar se uma mudança<br/>'encaixa' no design"]
    C --> P["Externalização PARCIAL<br/>(lossy)"]
    D --> P

Leitura do diagrama: setas cheias são o que se consegue externalizar; setas pontilhadas são o que se perde no caminho da mente para o artefato — e é justamente esse resíduo que distingue quem tem a teoria de quem só tem o texto.

As três capacidades da teoria

A teoria que um desenvolvedor tem de um programa lhe permite fazer três coisas. Naur as enumera, e elas são o teste prático de quem “tem a teoria”:

1. Mapear o programa ao mundo — explicar como o software se relaciona com o problema do mundo real que ele resolve; como cada parte do código corresponde aos assuntos do domínio.
2. Justificar a estrutura (o “porquê”) — explicar por que cada parte do programa está ali e como contribui para a solução; quais decisões foram tomadas, contra quais alternativas e sob quais restrições.
3. Evoluir com coerência — responder construtivamente a demandas de modificação e extensão; estender o programa de modo consistente com seu design, sem violá-lo.

Quem tem a teoria responde a essas três coisas. Quem só tem o texto, não.

E aqui está o sinal clínico de Naur para a “morte” do programa.

O estado de morte fica visível quando demandas de modificação não podem mais ser respondidas com inteligência — só com remendos às cegas.

flowchart TD
    TEO["A teoria do programa"]
    TEO --> M["1. Mapear ao mundo<br/>código ↔ domínio real"]
    TEO --> J["2. Justificar o porquê<br/>decisões, alternativas, restrições"]
    TEO --> E["3. Evoluir com coerência<br/>mudar sem trair o design"]
    M --> R["Responde a perguntas<br/>sobre o sistema"]
    J --> R
    E --> R
    R --> S["TEM a teoria"]
    NT["Só TEM o texto<br/>(código + docs)"] -.->|"falha nas três"| F["NÃO tem a teoria"]

Leitura do diagrama: as três capacidades convergem na habilidade de responder com sentido a qualquer pergunta sobre o sistema — e é exatamente essa habilidade que falta a quem herdou só o repositório.

A morte e o renascimento do programa

O corolário mais citado de Naur: um programa morre quando a equipe que detém sua teoria se dispersa.

Repare na palavra “morre”. O programa pode estar rodando perfeitamente em produção e, ainda assim, estar morto no sentido de Naur.

A morte aqui não é o crash. É a perda da capacidade de evoluí-lo com segurança.

O que resta é texto. Ele ainda executa.

Mas modificações feitas por quem não tem a teoria tendem a ser remendos que não se encaixam no design, degradando o sistema mudança após mudança. (É o motor do decaimento.)

E reviver? Reviver não é ler a documentação.

Naur

“Revival of a program is the rebuilding of its theory by a new programmer team.”

Reconstruir a teoria é trabalho lento, caro e que só pessoas podem fazer. Não se baixa de um repositório.

flowchart TD
    A["Equipe constrói o programa<br/>+ a teoria (juntos)"]
    A --> B["Programa VIVO<br/>evolui com coerência"]
    B --> C{"A equipe se<br/>dispersa?"}
    C -->|não| B
    C -->|sim| D["Programa MORTO<br/>ainda executa, mas..."]
    D --> E["Mudanças viram remendos<br/>que não encaixam no design"]
    E --> F["Decaimento acelera"]
    D --> G["RENASCIMENTO?"]
    G --> H["Reconstruir a teoria<br/>do zero — lento, caro, humano"]
    H --> B

Leitura do diagrama: a única seta que devolve um programa morto à vida é a da reconstrução da teoria por pessoas — e ela é cara justamente porque refaz o trabalho cognitivo que o código não guardou.

O caso de Naur: o compilador e a equipe que tinha o texto, mas não a teoria

A força do ensaio vem de um exemplo real que Naur descreve.

Um grupo A desenvolveu um compilador para uma linguagem L, e ele funcionava bem. Outro grupo B recebeu a tarefa de estender esse compilador para L + M — uma extensão modesta.

O grupo B teve toda a ajuda que se poderia pedir:

• documentação completa, com textos de programa anotados;
• farta discussão escrita de design;
• e aconselhamento pessoal do grupo A.

Mesmo assim, quando B propunha como acomodar as extensões e submetia ao grupo A para revisão, em vários casos importantes acontecia o mesmo.

As soluções de B ignoravam recursos que já estavam na estrutura do compilador — e que estavam, inclusive, documentados.

Em vez de usá-los, B propunha remendos — patches que destruíam a potência e a simplicidade do design original.

A documentação estava toda ali. O grupo B a tinha lido. E ainda assim não conseguia estender o sistema com coerência — porque não tinha construído a teoria. Tinha o texto; faltava a capacidade.

Esse é o ensaio inteiro em miniatura: o “o quê” estava escrito; o “porquê” e o julgamento de coerência não cabiam no papel.

Consequências práticas: o payoff sênior

Naur escreveu sobre filosofia da mente, mas a tese explica problemas concretos que todo time grande vive. Cada um deles vira óbvio quando você troca “código” por “teoria”.

Por que grandes rewrites fracassam

Reescrever do zero descarta o código — e, com ele, a teoria sedimentada nos casos de borda.

Joel Spolsky chamou a reescrita do Netscape de “o pior erro estratégico que uma empresa de software pode cometer”.

O argumento dele casa exatamente com Naur. As partes “feias” e crufty do código costumam ser conhecimento duramente ganho sobre bugs e cantos do problema.

Cada esquisitice é a cicatriz de um caso real. Apagar o código apaga a cicatriz — e o bug volta.

Na linguagem de Naur, o rewrite joga a teoria fora e obriga a reconstruí-la do zero — enquanto a concorrência avança.

O código novo é “limpo” justamente porque ainda não aprendeu nada. (Liga a 10 - Dívida técnica.)

A lição não é “nunca reescreva” — é “saiba que você está pagando para reconstruir uma teoria, não só para reescrever um texto”.

Onboarding é transferência de teoria, não leitura de docs

O melhor jeito de um novato adquirir a teoria, dizia Naur, é trabalhar lado a lado com quem a tem.

Documento ajuda; substituir o convívio, não. A teoria passa por osmose: ver o sênior decidir, ouvir o “porquê” no momento em que ele importa, errar e ser corrigido.

Por isso pareamento e revisão de código valem tanto. Não são só mecanismos para pegar bugs — são canais de transferência de teoria (theory-sharing).

Uma revisão que só aprova o diff perdeu metade do propósito. A que pergunta “por que aqui e não ali?” está movendo teoria de uma cabeça para outra.

Bus factor / truck factor

É a métrica direta da tese: o número mínimo de pessoas que precisam sumir para o projeto travar por falta de quem detém a teoria.

Bus factor de 1 significa um sistema que está vivo apenas porque uma pessoa específica não foi atropelada por um ônibus. Não é exagero retórico — é uma descrição honesta do risco.

A defesa não é “documentar mais” — já vimos que não basta.

É espalhar a teoria: pareamento, rodízio em áreas do código, code ownership compartilhado em vez de feudos individuais.

Cada uma dessas práticas eleva o número de cabeças que conseguem responder às três perguntas de Naur.

Integridade conceitual (Brooks)

Fred Brooks, em The Mythical Man-Month, chama a integridade conceitual de “a consideração mais importante no design de um sistema”: olhe onde olhar, e o sistema parece desenhado pela mesma mente.

Isso é a teoria de Naur feita coerente — e mantida coerente ao longo do tempo.

Brooks propõe um arquiteto-chefe (ou poucos) como guardião dessa coerência. A razão é a mesma de Naur: uma teoria única não sobrevive sozinha quando muitas mãos a tocam sem dono.

Quando a teoria se dilui entre muitas mãos sem coordenação, a integridade conceitual é a primeira coisa a se perder.

O sistema vira uma colcha de retalhos — cada parte pensada por uma teoria diferente, nenhuma falando com a outra.

Lei de Conway

Se a estrutura do sistema espelha a estrutura de comunicação da organização (ver 16 - Lei de Conway), então a teoria também é distribuída pela organização.

Cada time carrega a teoria da sua parte; as fronteiras entre times viram fronteiras entre teorias.

Reorganizar times sem cuidar dessas fronteiras de teoria fragmenta o entendimento do sistema. E a integração entre módulos sofre exatamente onde a comunicação entre as pessoas é mais fraca.

Como se preserva a teoria, na prática

Se a teoria é o ativo, a engenharia tem que tratá-la como tal. Algumas práticas comuns deixam de ser “boas maneiras” e viram preservação de teoria:

• Pareamento e mob programming — espalham a teoria em tempo real; transformam bus factor 1 em 2 ou 3 sem reunião extra.
• Revisão de código como diálogo — a pergunta “por quê?” no PR é teoria sendo transferida, não burocracia.
• ADRs (Architecture Decision Records) — capturam o “porquê” de decisões específicas no momento em que ele ainda está vivo. Não são a teoria, mas são a melhor captura parcial dela. (Ver 12 - Dívida de intenção.)
• Continuidade de pessoas — manter ao menos um desenvolvedor de “primeira geração” perto de cada parte crítica, como em Bjarnason.
• Não reescrever por impulso — antes de um rewrite, perguntar: temos a teoria do que vamos jogar fora, ou só estamos fugindo do que não entendemos?

Nenhuma dessas práticas substitui a teoria na cabeça das pessoas. Todas a espalham, capturam parcialmente ou protegem — que é o máximo que se pode fazer com algo majoritariamente tácito.

O resumo sênior em uma linha

O código você herda de graça. A teoria, você reconstrói no suor — então proteja as pessoas que a carregam tanto quanto protege o repositório.

Por que importa hoje

Naur já desafiava a “visão de produção” da programação: a ideia de que programar é fabricar texto.

Dessa visão decorre que programadores seriam intercambiáveis e que o processo poderia ser mecanizado por método.

Naur até observa um corolário desconfortável dessa mentalidade: a de que as pessoas trabalhariam melhor se agissem como máquinas, seguindo regras formais.

Para ele, isso é um erro de categoria — confunde o artefato com a teoria.

Se o programa é uma teoria, o ativo é a mente que a sustenta, não a linha de código.

O conceito ficou décadas relativamente esquecido e ressurgiu nos anos 2020.

Baldur Bjarnason (“Theory-building and why employee churn is lethal to software companies”, 2022) levou a tese à conclusão organizacional: a rotatividade constante de equipe é “o toque de finados” de um projeto de software.

O argumento dele é sobre gerações de teoria:

• a forma mais confiável de ter a teoria de um código é ter estado lá quando ele foi escrito;
• a segunda melhor é ter trabalhado com alguém que estava lá — um desenvolvedor de “primeira geração” à mão;
• a cada saída sem sobreposição, a teoria fica mais diluída, e a reconstrução, mais cara.

Por isso churn alto não é só um custo de RH. É um risco existencial para o sistema: cada pessoa que sai sem passar a teoria adiante leva embora um pedaço que nenhum documento guardou.

E há o ângulo da IA generativa — que pertence mais a IA / O Lado Sombrio da IA. Aqui, só o gancho.

A IA barateia a produção do texto sem necessariamente construir a teoria na cabeça de ninguém.

Gera-se o artefato pulando o trabalho de theory building — e o programa pode nascer já na condição de “morto” no sentido de Naur.

Esse é o mecanismo por trás do débito cognitivo — desenvolvido na nota 11 - Dívida cognitiva.

Limites e nuances

A tese é forte — e por isso vale marcar onde ela não deve virar dogma.

“Tudo é tácito”? Não. Naur não diz que nada se pode escrever; diz que o registro é sempre parcial. Boa parte do “o quê” se documenta muito bem. O que resiste é o “porquê” profundo e o julgamento de coerência. A conclusão prática não é “não documente” — é “não confunda o documento com a teoria”.

ADRs, specs e testes como captura parcial. A leitura moderna do ensaio (Barn & Clark, Revisiting Naur’s Programming as Theory Building, 2011) é direta: práticas como clean code, ADRs, story maps e testes são necessárias, mas não suficientes.

São secundárias ao construto mental compartilhado do time. Valem muito — só não substituem a teoria.

Um bom ADR captura uma decisão e seu porquê no instante em que ele está vivo. É o melhor que se consegue — e, ainda assim, é um fragmento. (Ver 12 - Dívida de intenção.)

Não é desculpa para não escrever nada. O risco de citar Naur é a preguiça travestida de filosofia: “documentar não adianta, então não documento”. Errado.

Como a captura é parcial, vale capturar o máximo do que dá — e investir o resto em transferência humana. As duas coisas, não uma só.

Lastro / honestidade

A enumeração das três capacidades, a definição de morte e a frase sobre o renascimento são de Naur (1985). Knowing-that/knowing-how e o argumento da regressão são de Ryle (1949); “sabemos mais do que conseguimos dizer” é de Polanyi (1966). A leitura organizacional (employee churn) é de Bjarnason (2022); a frase do rewrite é de Spolsky (2000); “integridade conceitual” é de Brooks. O ângulo da IA é gancho — o desenvolvimento está nas notas linkadas, não aqui. Tudo conferido nas fontes da seção Referências.

Armadilhas comuns

Confundir documentação com teoria

A nota inteira gira em torno disso, mas vale nomear o erro direto: documentação e ADRs são externalizações parciais da teoria, não a teoria em si. Uma equipe pode ter documentação impecável — como o grupo A deixou para o grupo B, no exemplo do compilador — e mesmo assim não conseguir transferir a capacidade de julgar o que “encaixa” no design. Documentar bem é necessário; tratá-lo como suficiente é o erro de categoria que Naur ataca desde a primeira página.

Achar que onboarding é ler código e docs

Se a teoria é majoritariamente tácita (Polanyi) e é uma capacidade, não um texto (Ryle), então nenhum volume de leitura solitária a transfere. Naur é explícito: o melhor canal é trabalhar lado a lado com quem já tem a teoria. Um onboarding que só entrega um wiki e um repositório para o novato “se virar” está otimizando o canal errado — e vai produzir alguém que sabe o quê, mas não por quê nem como julgar.

Tratar rotatividade como problema de RH

Churn alto não é só custo de recrutamento e ramp-up — é erosão direta da teoria do sistema, como argumenta Bjarnason. Cada saída sem sobreposição leva embora um pedaço do “porquê” que nenhum documento guardou. Encarar isso como métrica de retenção, e não como risco técnico ao próprio sistema, é subestimar o que realmente se perde quando a equipe se dispersa.

Inglês

O ensaio de Naur é em inglês, e boa parte do vocabulário técnico não tem tradução direta em português sem perder nuance.

Theory building é o termo do próprio Naur — “construção de teoria” funciona em português, mas “teoria”, aqui, carrega o sentido de Gilbert Ryle: não é hipótese científica testável, é a capacidade viva de explicar, justificar e responder a situações novas. Mais perto de “domínio prático” do que de “modelo teórico”.

Tacit knowledge é o conceito de Polanyi — conhecimento que se possui, mas não se consegue verbalizar por inteiro. “Conhecimento tácito” é a tradução padrão e não perde muito.

Program revival (e program death) são termos cunhados pelo próprio Naur no ensaio — não são jargão consagrado da indústria, o que vale marcar para quem for citar a fonte. “Reviver o programa” é uma tradução literal aceitável, desde que se preserve que “revival” ali é reconstrução da teoria por uma nova equipe, não recuperação de um sistema fora do ar.

Português	Inglês
construção de teoria	theory building
conhecimento tácito	tacit knowledge
renascimento do programa	program revival
morte do programa	program death
teoria no sentido de Ryle	Ryle’s sense of theory
saber proposicional	knowing-that
saber-fazer / capacidade	knowing-how
transferência de teoria	theory-sharing

Em entrevista

Pergunta típica: “Por que documentar mais não resolve o problema de conhecimento de um sistema legado?”

Resposta curta, ancorada em Naur: porque o conhecimento crítico é uma capacidade (Ryle, knowing-how) e majoritariamente tácito (Polanyi).

A documentação captura o “o quê”, não o “porquê” nem o julgamento de coerência. Ela ajuda quem reconstrói a teoria, mas não a transfere.

Por isso pareamento, revisão e continuidade de pessoas importam mais que volume de docs — e por isso bus factor baixo é risco real, não burocracia.

Se sobrar tempo, o gancho de profundidade é o exemplo do compilador de Naur (grupos A/B): a doc completa não impediu B de propor remendos, porque B não tinha a teoria.

O que vem a seguir

Se a teoria é majoritariamente tácita, e o código só carrega um registro com perda dela, sobra uma pergunta prática: o que, exatamente, o texto do programa consegue carregar?

Não tudo — já vimos isso. Mas não nada, também. Há um mecanismo específico com que uma equipe empacota parte da sua teoria dentro do próprio código, de um jeito que outras pessoas não precisam reconstruir a decisão inteira para usá-la com segurança.

Esse mecanismo é a abstração: a unidade que esconde uma decisão atrás de uma interface simples, para que quem chama não precise carregar na cabeça tudo o que quem escreveu carregou. Parnas dá o critério de onde traçar essa linha — e é dele que parte a próxima nota.

Ver 05 - Abstração - a ferramenta central.

Referências

Assista — Peter Naur — Programming as Theory Building

Computer Science Off Course · 41min · Peter Naur — Programming as Theory Building Leitura e discussão do ensaio de 1985 que fundamenta esta nota. Útil especialmente para o ponto mais escorregadio: o sentido de “teoria” em Ryle, que não é hipótese científica e sim capacidade de explicar, responder e estender.

• Peter Naur — Programming as Theory Building (1985). Microprocessing and Microprogramming, vol. 15, pp. 253–261. Reimpresso em Computing: A Human Activity (ACM Press, 1992). O exemplo dos grupos A/B (o compilador) é o “Case 1” do ensaio. PDF (gwern.net) · PDF (UW-Madison) · texto (gist)
• Gilbert Ryle — The Concept of Mind (1949), cap. 2 “Knowing How and Knowing That” — a distinção knowing-that × knowing-how e o argumento da regressão contra a intellectualist legend. Ver também SEP — Ryle on Knowing-How.
• Michael Polanyi — The Tacit Dimension (1966) — conhecimento tácito; “we can know more than we can tell” (o “paradoxo de Polanyi”); a estrutura from-to entre awareness subsidiária e focal. Ver Wikipedia — Tacit knowledge e Polanyi’s paradox.
• Fred Brooks — The Mythical Man-Month (1975) — “conceptual integrity” como “a consideração mais importante no design de um sistema”.
• Joel Spolsky — Things You Should Never Do, Part I (2000) — por que reescrever do zero descarta conhecimento sedimentado (caso Netscape). joelonsoftware.com
• Baldur Bjarnason — Theory-building and why employee churn is lethal to software companies (2022) — a releitura organizacional da tese de Naur. baldurbjarnason.com
• Bus factor (truck/lottery factor) — número mínimo de pessoas cuja perda trava o projeto por falta de quem detém o conhecimento. Wikipedia
• Balbir Barn & Tony Clark — Revisiting Naur’s Programming as Theory Building for Enterprise Architecture Modelling (CAiSE 2011) — a leitura de que ADRs, testes e clean code são captura parcial, “necessária mas não suficiente”. PDF
• Peter Naur (biografia) — cientista da computação dinamarquês (1928–2016), editor do relatório ALGOL 60, Prêmio Turing 2005, defensor da datalogy. Wikipedia

Veja também

• 01 - A complexidade como problema central — abre o galho Complexidade de Software, onde esta nota é a fase Iniciado
• 11 - Dívida cognitiva — a erosão dessa teoria em nível de projeto, sob a lente geral
• 10 - Dívida técnica — o que se acumula quando se mexe no programa sem a teoria; e por que rewrites fracassam
• 12 - Dívida de intenção — ADRs e specs como captura parcial do “porquê” da teoria
• 16 - Lei de Conway — a teoria também é distribuída pela estrutura da organização
• 13 - Entropia de software e decaimento — o decaimento como sintoma de remendos sem teoria
• 15 - Pensamento sistêmico — o software como sistema sociotécnico de pessoas + código + processo
• Comprehension gate — a prática que defende a teoria mudança a mudança
• Débito cognitivo — a erosão, em nível de projeto, dessa teoria sob a lente da IA (Storey, 2026)
• Cognitive debt — Margaret-Anne Storey (DX) — a glosa que conecta Naur ao contexto de IA
• Dicionário de Ciência da Computação — verbete Programação como construção de teoria (theory building)