A Note on Essential Complexity

The post treats managing complexity as the core duty of software engineers, then revisits the distinction between essential and accidental complexity. It argues that some complexity labeled essential can be reduced when engineers question requirements and help redefine the problem.

Reading notes

#

• Software engineers can be described in several ways, including writing code, building software, delighting users, solving problems, and making money.
• These goals come from different models of the world and can conflict with one another.
• The post assumes that managing complexity is the main duty of a software engineer.
• Complexity is defined as anything that makes a system hard to understand and modify.
• Ousterhout argues that reducing complexity is central because most code is written by extending existing systems.
• Brooks distinguishes between essence and accident in software, and says complexity is an essential difficulty of software systems.
• Moseley and Marks define essential complexity as inherent in the problem as users see it, and accidental complexity as the rest.
• The user’s point of view matters because if users do not know about a thing, it cannot be essential by this definition.
• The engineer’s task is to minimize accidental complexity and assist with essential complexity.
• The post challenges the idea that essential complexity is fully irreducible.
• Brooks is cited to show that software must often conform to external interfaces and human institutions.
• The post argues that software can also change user behavior and organizational expectations.
• If users adapt to the system, the problem definition itself can change.
• From that perspective, the engineer’s goal becomes minimizing complexity of any kind.
• Brooks is quoted again to support the idea that many system complexities reflect organizational malfunction.
• Redefining requirements is presented as normal senior engineering work, including asking why a feature is needed and whether a smaller version would do.
• If a user accepts a change in requirements, the removed complexity was not essential after all.
• Without engineers questioning assumptions, unnecessary features can become fixed into the problem specification.
• For complex systems or organizations, complexity may be accidental, essential, redefinable, or impossible to classify because knowledge is lost.
• Legacy software is used as an example where the system itself becomes the only specification.
• Bellotti’s example shows systems being turned off to learn what they do; if no one complains, they may stay off.
• Even when systems cannot be removed, the information gained can reduce organizational complexity.
• The argument is taken to an extreme by imagining engineers reshaping organizations around simpler systems.
• The post closes by warning that this reasoning has limits and that engineers should not hide behind abstractions when their work affects people and organizations.