i

Description

Denver International Airport

Source

author not stated · original page

Licence

PD Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Over-engineering

A ten-layer solution looks more professional than a two-layer solution, and that's exactly what makes it dangerous.

In brief

• What: we design bigger, more general, and more sophisticated than the need requires.
• Why: complexity is seen as seriousness, we want to “be ready for what comes next,” and the designer likes their own work.
• Detect: abstractions without a second use, options nobody asked for, a design that takes longer to explain than to build.
• Avoid: start from the current need, generalize only on the second or third real use, have the simplest solution defended in review.

On this page

1. Definition
2. How it works
3. Where you encounter it
   1. In project management
   2. In management
4. Famous cases
   1. The Denver airport baggage system 1993-1995 (abandoned in 2005)
   2. The second-system effect (Brooks) 1975
   3. FizzBuzz Enterprise Edition humorous project, public repository
5. Detection signals
6. Avoidance reflexes
7. With AI: detect, fix, mitigate
   1. Detect
   2. Fix
   3. Mitigate
   4. Prompts to integrate into your practices
   5. How to integrate them
   6. Precautions
8. Limits
9. Sources and verification
10. See also
    1. Combines with, or reinforces
    2. Related biases
    3. Counterweights and related reflexes

Definition#

Fictitious illustration

Over-engineering (over-engineering) means designing a solution that's more complex than the problem requires: too many layers, too many parameters, too much generality, too much precision. It's not a cognitive bias in the strict sense, but the result of a set of well-described tendencies: we treat sophistication as a sign of quality, overestimate future needs, and become attached to what we've imagined.

The best-known case is the second-system effect, described by Frederick Brooks in The Mythical Man-Month (1975): the designer delivering their second system pours into it all the ideas and features they had to leave out the first time, making it, according to Brooks, “the most dangerous system” they will design. The methodological countermeasure is called YAGNI (You Aren't Gonna Need It, from Extreme Programming): don't write what you don't need today.

How it works#

Several tendencies combine:

• Sophistication as proof of seriousness: a multi-layer architecture, a rules engine, or an in-house framework impresses in review; a twenty-line solution seems “lightweight.”
• Optimism about the future: we imagine needs that will come later (other clients, other databases, other languages) and build for them, without measuring the cost of carrying that generality today, or the likelihood that those needs will actually materialize.
• The designer's enjoyment and image: an interesting problem is more motivating than a mundane one; a clever solution enhances its author. The The IKEA effect then reinforces attachment.
• Asymmetry of criticism: “it wasn't flexible enough” is said in meetings; “it's too complicated” gets said only later, when the team has already paid for it.

Complexity has a simple calculable property: the number of possible relationships between components grows much faster than the number of components. Between n components, there are up to n(n − 1) / 2 pairs that can influence each other.

Where you encounter it#

In project management#

• Architecture: microservices, event bus, or workflow engine for an application used by forty people; a “database-agnostic” design even though the product will only ever use one.
• Premature generalization: an interface, a factory, and three inheritance levels for a case that has only one implementation.
• Excessive parameterization: everything becomes configurable, until configuration itself is a programming language that's harder to test than code.
• Imagined non-functional requirements: “it needs to handle ten times the current load” without a growth scenario or measurement.
• Tooling: a delivery pipeline and environments sized for a team ten times larger.

In management#

• Process: a five-level approval workflow for a decision worth a few hundred dollars; a four-page meeting-notes template for a fifteen-minute meeting.
• Organization: a forty-criteria evaluation grid, or a skills matrix that takes longer to maintain than to use.
• Methodological framework: adopting the most complete version of an agile or quality framework “to be serious,” when the team needs three practices.
• Reporting: a dashboard with thirty indicators, four of which are actually consulted.

Famous cases#

Detection signals#

• An abstraction has only one implementation and no second one is planned by the project deadline.
• “Just in case…,” “for later,” “this will be useful when we have…” in justifications.
• It takes more time to explain the design than to build it.
• Newcomers need weeks before they can make a simple change.
• Options, parameters, or fields that nobody uses since production release.
• The solution consumes more platform resources (CPU, licenses, administrators) than the problem it solves.
• A one-line change requires touching five files.

Avoidance reflexes#

1. Start from a verified need. For each design capability, ask: who requested it, for when, and with what evidence? A need without a requester is a hypothesis.
2. Apply YAGNI. Don’t build what you don’t need today, unless adding it later would clearly cost much more than now (a rare case, to be justified).
3. Generalize on the second or third real use, not the first. Two cases sketch an abstraction poorly; three cases sketch it better.
4. Have someone defend the simplest solution. In a design review, someone’s role is to explain why a simpler version would not be enough.
5. Quantify complexity. For each added layer: development, testing, operations, and training cost. Show it next to the expected benefit.
6. Deliver small, first. A first minimal version in production teaches more than ten weeks of design. This is Gall’s principle: a complex system that works is always evolved from a simple system that worked.
7. Plan a simple plan B before committing to an ambitious solution, as in the Denver case.
8. Clean up. Remove what is not used: an option never enabled in production for a year is a candidate for removal.

With AI: detect, fix, mitigate#

Prompts to integrate into your practices#

1. Simple version advocate. To use in design review, on an architecture file.

Here is the proposed design for [feature / system]: [description].
Here are the confirmed requirements (with their source): [list].
Play the role of simplicity advocate. 1) Propose the simplest version that satisfies the confirmed requirements, describing it in fewer than fifteen lines. 2) For each element of the proposed design that is not in this version, say which requirement it addresses, or indicate that it addresses no confirmed requirement. 3) State what would become difficult if we chose the simple version, without exaggerating.
Do not try to validate the initial design.

2. Module complexity audit. On a code excerpt or a class list, after anonymization.

Analyze this code: [code or component list].
Identify: interfaces or abstract classes that have only one implementation, parameters or options never used in the provided calls, layers that only pass through a call, and cases where the number of files touched for a simple change seems excessive.
For each point, indicate your confidence (certain, likely, to be checked) and what would need to be checked in the rest of the repository before deleting anything.

How to integrate them#

• Before the review: prompt 1 is run by the author themself, who answers objections before the meeting.
• Day to day: put a restraint instruction in your code assistant configuration file, and review its proposals like those of an overzealous junior.
• In retrospectives: prompt 2 feeds a point titled “what we built that nobody uses.”

Precautions#

• AI can judge something unnecessary when it addresses a requirement it does not know about (regulation, operational constraint). Give it the requirements; do not let it decide by itself what to remove.
• The proposed “simple” version may ignore edge cases: test it.
• Do not send confidential code to an unauthorized tool.

Limits#

• Under-engineering also exists: a solution that is too minimal is expensive to rework when the need is real and foreseeable (security, compliance, personal data). The point is not to reject all anticipation, but to justify it.
• Over-engineering is not always a bias: it can result from contractual requirements, an imposed specification, or a lack of time to make it simpler (“I did not have time to write a shorter text”).
• There is no objective measure of the “right” complexity: judgment remains contextual, and two experts can honestly disagree.
• The Denver case figures come from the October 1994 GAO report; later assessments vary depending on what is counted.

Sources and verification#

• Brooks, F. P. (1975), The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley (anniversary edition 1995) — chapter “The Second-System Effect.”
• U.S. General Accounting Office (October 1994), New Denver Airport: Impact of the Delayed Baggage System, RCED-95-35BR — dates, costs, and cost of delay.
• Gall, J. (1975), General Systemantics: An Essay on How Systems Work, and Especially How They Fail (reissued in 1977 under the title Systemantics: How Systems Work and Especially How They Fail) — the statement behind “Gall’s law.”
• Fowler, M., “Yagni,” martinfowler.com — origin and limits of the principle.
• Beck, K. (1999), Extreme Programming Explained: Embrace Change, Addison-Wesley.
• Knuth, D. E. (1974), “Structured Programming with go to Statements,” ACM Computing Surveys — the warning about premature optimization.
• EnterpriseQualityCoding, FizzBuzzEnterpriseEdition (GitHub repository) — parody.

See also#