11 Rediscovering Principles
Beneath methodology lie principles: abstraction and information hiding, technical debt, the isomorphism between organizational structure and system structure, essential complexity and accidental complexity, and the exchange law of people and time. This chapter is about how papers from half a century ago read anew in the age of context windows and agents.
11.1 Abstraction and Information Hiding: Why Parnas Was Right, Again
Pre-draft. See TOPICS.md at the repository root for owner and status.
Brief. This section contrasts Parnas’s (1972) information-hiding criterion, the argument that modules should be divided not by function but by decisions likely to change, with codebase design in the era of AI agents with finite context windows. It is written in three parts. First, it reads precisely the two module decomposition approaches that Parnas’s original paper compared. Second, it gathers cases where the way AI agents handle code demands this same criterion anew. Third, it argues whether a principle devised for human cognitive limits holds in the same form for a model’s context limits.
Seed Questions
- What exact examples did Parnas (1972) use to compare the two module decomposition approaches he discussed, namely flowchart-based decomposition and information-hiding-based decomposition? (verify against the original)
- Parnas grounded information hiding in ease of change, an argument aimed at reducing the cognitive burden on human programmers. Does this argument carry over directly to AI agents with finite context windows, or do agents’ limits differ in kind, requiring a different decomposition criterion? (verify against the original)
- Are there cases where official documentation or practical guides for agentic coding tools explicitly recommend codebase structures that are easy for agents to work with, and if so, how much do they overlap with Parnas’s information-hiding criterion? (collect rediscovery cases)
- How many refactoring cases or discussions claiming to produce “AI-friendly” repository structures (small files, clear filenames, preference for pure functions, etc.) can be found? (collect rediscovery cases)
- Compared to other modularization principles developed after Parnas (cohesion and coupling, SOLID, etc.), why does the AI-era rediscovery concentrate specifically on information hiding?
- Is the question of what to show, as discussed under context engineering (§3.2 of this book), the same problem as Parnas’s module boundary problem under a different name, or a different problem altogether?
Research Pointers
- Parnas, “On the Criteria to Be Used in Decomposing Systems into Modules” (1972), original text
- Points of contact with §3.2 (Context Engineering) and §5.3 (The Art of Context Management) of this book; avoid duplicating content
- Guides recommending repository structures for agentic coding tools (official documentation, engineering blogs)
- Comparative materials on later modularization theories such as cohesion and coupling
I have enough convention examples (“verify against the original source” for 원전 확인, “collect rediscovery cases” for 재발견 사례 수집). Now producing the translation.
11.2 Technical Debt: When a Metaphor Met an Interest Rate
Not yet drafted. Check ownership and status in TOPICS.md at the repository root.
Brief. This section contrasts the original meaning of the technical debt metaphor, first used by Cunningham in his OOPSLA 1992 experience report, with its revival in the age of AI coding, where the speed of generation has sharply outpaced the speed of debt accumulation. The section is structured in three parts. First, it reads closely what Cunningham actually said and how the metaphor has since been misused. Second, it gathers case studies of debt-related discussions in the AI era and empirical investigations into the maintenance costs of generated code. Third, it argues whether the original metaphor’s distinction between deliberate debt with a repayment plan and reckless debt still applies to AI-generated code.
Seed Questions
- What exactly did Cunningham say and in what context in his 1992 OOPSLA experience report, and if he later commented on the misuse of this metaphor, what did he say? (verify against the original source)
- Cunningham’s original argument was closer to saying that taking on debt is not itself bad, but that the debt must be recognized and a repayment plan must be set. How much of this conditional character survives in how the term technical debt is used today? (verify against the original source)
- Does empirical research or data exist to support the claim that technical debt is rising sharply for code generated quickly by AI? (collect rediscovery cases)
- Are there cases that literally extend the interest rate metaphor to quantitatively discuss the interest rate of AI-generated code, and if so, what metrics did they use? (collect rediscovery cases)
- Is the distinction between deliberately taking on debt (for rapid prototyping) and recklessly taking on debt (accepting AI output as-is without verification) actually observed in AI coding workflows?
- The concept of technical debt has a history of attempts at quantification (debt metrics, static analysis tools). Are there similar attempts at quantification for AI-generated code?
Research Pointers
- The original text of Cunningham’s OOPSLA 1992 experience report (verify the exact title and quotations)
- Check whether Cunningham himself commented on the misuse of the metaphor in later interviews
- Division of labor with §9.3 (Quality Debt and Maintenance) of this book. That section focuses on the current state of affairs; this section focuses on the history and revival of the metaphor itself
- Recent empirical research or industry reports on the maintenance costs of AI-generated code
11.3 Conway’s Law and Human-AI Organizations
Not yet drafted. See TOPICS.md at the repository root for owner and status.
Brief. This section contrasts the thesis of Conway’s (1968) original paper, the observation that system design mirrors the communication structure of the organization that built it, with the code structure of organizations that mix humans and agents. It is written in three parts. First, read the exact claim and evidence of Conway’s original paper. Second, gather cases related to the code structure of organizations that mix humans and AI. Third, argue whether the mechanism of communication cost that Conway presupposed operates the same way for AI agents, actors fundamentally different from humans.
Seed Questions
- What exactly were the cases and arguments Conway actually used in his 1968 paper, that is, the observation that a committee’s design output resembles the committee’s own structure? (verify original source)
- Did Conway himself coin the name “Conway’s Law” and the term “inverse Conway maneuver” (the strategy of designing the organization first to match the desired architecture), or were these terms attached later by others? (verify original source)
- In a work structure where one person directs multiple agents at once, what should the thesis that organizational structure resembles code structure be understood as resembling: the cognitive structure of the single director, or the communication protocol among the agents?
- Has there been any reported case of an organization operating a multi-agent system deliberately applying the inverse Conway maneuver, that is, designing the agent organization structure first in order to obtain the desired software architecture? (gather rediscovery cases)
- Communication cost, commonly cited as the mechanism behind Conway’s Law, consists among humans of meetings, documentation, and trust-building; what does communication cost among agents consist of, and does this change whether the law holds?
- Is the design of multi-agent frameworks itself already conscious of Conway’s Law, that is, are there cases where tool designers cited this law to justify their architecture? (gather rediscovery cases)
Research Pointers
- Conway, “How Do Committees Invent?” (1968), the original paper (verify original publication venue)
- The origin of the term “inverse Conway maneuver” (verify whether it was Conway himself or a later compiler)
- Design documents of multi-agent coding systems, practitioners’ accounts of operating agent organizations
- Points of overlap with related sections in Chapter 14 of this book (The Reorganization of Work); avoid role duplication
11.4 No Silver Bullet, Revisited
Pre-draft. Check TOPICS.md at the repository root for owner and status.
Brief. This section contrasts the distinction Brooks (1986) drew between essential and accidental complexity, along with his claim that no single technology will yield a tenfold productivity gain, with which kind of complexity LLM coding tools actually reduce. It is written in three parts. First, it reads closely the original Brooks paper’s distinction between the two kinds of complexity and his assessment of the promising techniques he reviewed. Second, it gathers empirical studies on the productivity of LLM coding tools as cases. Third, it argues whether the grounds on which Brooks concluded there is no silver bullet still apply to LLMs, or whether LLMs are a kind of solution he did not anticipate.
Seed Questions
- What were the exact definitions of essential and accidental complexity that Brooks distinguished in “No Silver Bullet” (1986), and what examples did he give for each? (verify against the original)
- In the paper, Brooks already considered artificial intelligence as a candidate silver bullet and rejected it. What exactly were his grounds for rejecting it, and do those grounds still hold for today’s LLMs? (verify against the original)
- Do empirical studies measuring the productivity gains of LLM coding tools distinguish whether the gains come from reducing essential complexity or accidental complexity (typing, syntax, boilerplate)? (gather rediscovery cases)
- Are claims that LLMs are finally the silver bullet actually contending with counterarguments that LLMs, in the end, only reduce accidental complexity? If so, what is the core argument on each side? (gather rediscovery cases)
- One of the reasons Brooks concluded there is no silver bullet was that software’s essential difficulties (complexity, conformity, changeability, invisibility) do not disappear even when the form of representation changes. Which of these four difficulties, if any, does the new representational form of natural-language prompting actually reduce?
- Has Brooks himself, in later interviews or writings, revisited his 1986 predictions? If so, what did he reaffirm or revise?
Research Pointers
- Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering” (1986), original text
- Later software engineering literature dealing with the distinction between essential and accidental complexity
- Empirical studies on LLM coding productivity (industry and academic surveys)
- Points of contact with Chapter 4 (Opportunities and Potential) and Chapter 8 (How It Works) of this book; this section focuses on a reassessment through Brooks’s framework
11.5 Mythical Man-Month: From Person-Months to Agent-Hours
Pre-draft. Check ownership and status in TOPICS.md at the repository root.
Brief. This piece contrasts Brooks’s (1975) core law, the claim that adding manpower to a late project makes it later, and its rationale, with the recent practice of adding more agents in parallel. It is structured in three parts. First, read Brooks’s law and its communication-overhead rationale precisely from the original text. Next, gather cases of parallel operation where multiple agents are run simultaneously. Finally, argue whether adding people and adding agents are the same or different in terms of the communication-overhead mechanism.
Seed Questions
- What was the exact argument by which Brooks (1975) derived the law that adding manpower to a late project makes it later, and specifically, as what function of headcount did he calculate the number of communication paths growing? (verify in the original text)
- Brooks’s argument also cited the cost of training newcomers and the difficulty of dividing work sequentially as grounds; how does each of these two grounds apply, or fail to apply, to the situation of deploying additional agents? (verify in the original text)
- Is there any case or report on whether running multiple agents in parallel, each assigned to a different part of the same project, actually reduces total completion time, or whether it is offset by human coordination costs? (collect rediscovery cases)
- If the core mechanism underlying Brooks’s law is communication overhead among people, does a corresponding overhead exist among agents, and if so, what is it measured by (token cost, context-sharing failure, conflicting changes, etc.)?
- Does writing by practitioners or researchers exist that explicitly claims Brooks’s law does not apply to agents, or conversely that it applies to them unchanged? (collect rediscovery cases)
- How are the surgical team model and the importance of conceptual integrity, which Brooks presented together in the same book, being reexamined in discussions of agent orchestration?
Research Pointers
- Brooks, “The Mythical Man-Month” (1975), original text (check the relevant chapter)
- Practitioner writing and tool documentation on multi-agent parallel coding operations (parallel subagents, running multiple worktrees simultaneously, etc.)
- Points of overlap with §8.2 of this book (Agent Anatomy); avoid duplicating roles