Simplicity

As explained in Functional Design and Architecture: Examples in Haskell

Simplicity is a property of software that limits unnecessary complexity and makes its behavior easier to understand and change.

Simplicity limits unnecessary complexity so software remains understandable, maintainable, and changeable. It helps teams support existing code, find and fix bugs, and give newcomers a usable path into the project. section 1.2.1

Treat simplicity as one success factor that must be balanced against delivery and requirements:

• Accomplish the goals: deliver the system when needed while managing quality, budget, deadlines, support, and risk. section 1.2.1
• Meet the requirements: provide the agreed functions and properties and make the system work correctly. section 1.2.1
• Preserve constant simplicity: keep the code understandable so refactoring, testing, maintenance, and bug fixing remain affordable. section 1.2.1
• Choose compromises consciously when fully satisfying every factor is unattainable. section 1.2.1

A maintainability decision

A complicated implementation may satisfy today’s requirement, but colleagues who join later can struggle to understand or modify it. A simpler implementation may require deliberate design effort, yet its lower support cost leaves more capacity for refactoring and testing. The practical choice is not “simple at any price,” but a conscious balance among simplicity, goals, and requirements. section 1.2.1

Figure 1.4 Compromising between simplicity, goals, and requirements

Use the trade-off diagram to compare simplicity with goals and requirements rather than treating simplicity as an isolated target. section 1.2.1

Table 13.1 Comparison of approaches (view table figure)

	Simplicity	Boilerplate	Convenience	Advanced language features
Free monads	Simple	Some	Not for this task	Nothing special
Final tagless	Simple	Some	Probably not	Type classes, phantom types, wrapped monads
GADTs	Very simple	Almost none	Very convenient	GADTs
Service handle	Very simple	Almost none	Very convenient	Nothing special
ReaderT	Very simple	Much (due to lifting)	Probably not	Nothing special

Use the comparison table to examine how functional design approaches trade simplicity against boilerplate, convenience, and advanced language features. section 13.2.7

How Functional Design and Architecture: Examples in Haskell covers it

How deep it goes

Explains simplicity through maintenance consequences and design trade-offs, then compares approaches without prescribing a universal winner.

Examples

Uses newcomer maintenance scenarios, maintainability-cost trends, trade-off diagrams, and comparisons of functional design approaches.

What you can do after

Evaluate design approaches consciously by weighing simplicity, boilerplate, convenience, language features, goals, and requirements.

How it connects

Connects simplicity with maintainability, refactoring, testing, dependency injection, services, coupling, and functional design.

liveBookmanning.com

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

Also explained in

• 

  liveBookmanning.com
  Machine Learning System DesignSimplicity is the property of having relatively few concepts, dependencies, or implementation details that must be understood or managed.
• 

  liveBookmanning.com
  The Art of CodeSimplicity is the quality of expressing software behavior with minimal unnecessary complexity while preserving its essential structure.
• 

  liveBookmanning.com
  API Design PatternsSimplicity is the API design quality of exposing desired functionality straightforwardly without unnecessary user-facing complexity.

Compare how 4 books explain simplicity →

Related concepts

• complexitycontrasts with · Complexity is the degree of difficulty in understanding, analyzing, changing, or operating a system or problem, arising from its structure, behavior, or interacting parts.
• consistencycontrasts with · Consistency is the property of related data, behavior, outputs, or states agreeing with one another or conforming to defined rules across relevant instances or operations.
• kissequivalent to · KISS is a design and problem-solving principle that favors keeping systems and solutions as simple as their requirements permit.
• expressive powerused by · Expressive power is the capacity of a model, language, or system to represent or convey a range and complexity of functions, patterns, distinctions, or ideas.
• maintainabilityproduces · Maintainability is the degree to which software can be understood, modified, corrected, tested, repaired, or kept operational with reasonable effort over time.
• storytellingused by · Storytelling is a communication technique that conveys information, ideas, or experiences through a structured and coherent narrative.

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.