Accidental complexity

As explained in Functional Design and Architecture: Examples in Haskell

Accidental complexity is complexity introduced by implementation choices, tools, or code rather than inherent requirements of the problem domain.

Accidental complexity is complexity added by implementation choices, tools, abstractions, or code rather than by the problem domain itself. Tricky code and unjustified solutions increase it; good design keeps it low without eliminating useful abstractions. section 1.3

Control accidental complexity by weighing design choices against their costs:

• Prefer solutions that expose domain behavior instead of unrelated implementation details. section 1.3
• Avoid both under-abstraction, which increases coupling, and overdesign, which adds unnecessary machinery. section 1.3
• Use interfaces, modularity, low coupling, high cohesion, and suitable type systems to make design decisions more conscious. section 1.6

A safer domain model

A unit mismatch caused a program to return pound-seconds where newton-seconds were required. Domain-oriented abstractions and static types can reduce the implementation detail developers must reason about and make invalid operations harder to express. section 5.1

Figure 1.6 Accidental and essential complexity of two solutions

Compare two imagined solutions and see how their technologies contribute differently to essential and accidental complexity. section 1.3

How Functional Design and Architecture: Examples in Haskell covers it

How deep it goes

Defines the distinction, explains abstraction trade-offs, and stops short of prescribing a universally best solution.

Examples

Uses competing solution weights, a spaceship API, a unit-mismatch failure, and domain-specific language design as concrete illustrations.

What it assumes

Assumes familiarity with software design and programming paradigms while distinguishing domain requirements from implementation choices.

What you can do after

Evaluate design choices and reduce unnecessary complexity using abstractions, interfaces, modularity, coupling, cohesion, and types.

How it connects

Connects essential complexity with abstraction, domain-driven design, DSLs, coupling, cohesion, modularity, and type systems.

liveBookmanning.com

Read Functional Design and Architecture: Examples in Haskell on liveBook Get the book at manning.com

Related concepts

• essential complexitycontrasts with · Essential complexity is the unavoidable difficulty inherent in a problem’s domain, rules, and required outcomes, which cannot be removed without sacrificing necessary behavior.
• migrationproduced by · A migration is a process of transferring or transforming data, software, or system state from a source form or environment to a target form or environment.
• complexitykind of · Complexity is the degree of difficulty in understanding, analyzing, changing, or operating a system or problem, arising from its structure, behavior, or interacting parts.
• domain-specific languageproduced by · A domain-specific language is a specialized language, notation, or terminology tailored to express concepts and tasks within a particular subject domain.
• abstractionaddressed by · Abstraction is a simplified representation that exposes relevant properties or behavior while omitting lower-level details unnecessary for a given purpose.
• refactoringaddressed by · Refactoring is the restructuring of existing software or code to change its internal organization and improve its design, typically while preserving externally observable behavior.

This explainer was generated by Manning's knowledge graph from the text of Functional Design and Architecture: Examples in Haskell. The section links point to the parts of the book it draws on.