Why SOLID is bad...

and everything Bob Martin says is highly suspicious

đź“ś Today's Menu

  • Principles, practices, and slogans

  • Why SOLID is bad

  • The two core principles of Agile

  • User-centric design

Code Metrics

Principle

A principle is a guiding truth that remains valid across tools, languages, and fads.

Principles are few, stable, and context-agnostic.

It describes why you act, not how.

Practice

A practice is a repeatable way of working that applies one or more principles.

Practices are tools, not truths.

It is situational and evolves with technology or culture.

Slogan

A slogan is a simplified statement that once hinted at a principle or practice but became detached from its rationale.

It’s often used as dogma instead of guidance.

What is SOLID?

SOLID is a group of five object oriented design principles coined by Robert C. Martin in the early 2000s and popularized by the software craftsmanship movement as a way to structure maintainable systems.

Single responsibility

  • No one wants god classes
  • What is a responsibility anyways?
  • Why a single responsibility?

Reality check!
Keep classes small
Keep classes self-contained
Encapsulate properly

Every class should have only one responsibility

Open/Close

  • No one cares about this
  • And in any case it's just wrong

Reality check!
Class inheritance is usually not the way
Modifying classes is perfectly fine

Software entities should be open for extension, but closed for modification

Liskov

  • Design by contract
  • Irrelevant unless you have hierarchies

Reality check!
Why are you inheriting or implementing interfaces?

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it

Interface Segregation

  • No god interfaces
  • No interfaces
  • See single responsibility

Reality check!
Why are you inheriting or implementing interfaces?

Clients should not be forced to depend upon interfaces that they do not use

Dependency Inversion

  • Every problem can be solved by another layer of abstraction
  • Except the problem of too many layers of abstraction

Reality check!
The trade-off of adding abstractions and complexity versus keeping the code simple is a fundamental choice

Depend upon abstractions, not concretes

There is no empirical or peer-reviewed scientific evidence validating the SOLID principles as predictors of code quality, maintainability, or developer productivity.

What is SOLID?

Solid is a slogan.

Bob C. Martin

Bob Martin built a personal brand and consulting business around promoting SOLID. The principles are a cornerstone of his public persona, driving sales of training materials, speaking engagements, and corporate coaching under the “Uncle Bob” brand.

Actually...

Uncle Bob invented SOLID while making photocopier software:

  • It was embedded code (hard to change)
  • It was either C++ or Java
  • It was a huge, slow enterprise environment
  • It was a "plugin" system where everything derives from a single class

Principles

In a good codebase:

  • It's cheap to add or change features
  • It will be cheap next year, too

A good team:

  • Is focused on delivering features fast
  • Cleans up after themselves
  • Makes itself faster

Simplicity

Don't add complexity
(abstractions, classes, interfaces,
tools, libraries, tests ...anything!)
that you don't need right now.

Remove complexity!

Simplicity–the art of maximizing the amount of work not done–is essential.

Cohesion

All code that you need to change should ideally live on a single screen.

Keep related logic together.

  • Multiple locations add complexity
  • Multiple files add complexity
  • Multiple systems add complexity

Clean up

Can you make some code simpler? Go ahead, the future gain likely pays for it.

Implement new versions of frameworks, servers, libraries aggressively. Keep the technical debt down. Remember ESPx.

YAGNI

You ain't going to need it

DRY WET AHA

  • Don't repeat yourself
  • Write everything twice
  • Avoid hasty abstractions

Some good practices

Anti-patterns


Known things which are bad™️
https://en.wikipedia.org/wiki/Category:Anti-patterns

 

Code smells

 

Things that should make you go: hmmmm
https://en.wikipedia.org/wiki/Code_smell

DB first design

Start from the data model, define tables and relationships, and let the database schema drive the structure of the code and API.

This approach ensures data integrity and performance are prioritized, but can constrain flexibility when business needs change quickly.

Class first design

Begin by modeling real-world concepts as classes, then derive persistence and APIs from that model.

It favors encapsulation and reuse, though it can drift toward abstraction and mismatch with how data actually lives in storage.

Test driven design

Write tests before writing code, allowing tests to define desired behavior and drive implementation.

It aims to improve design quality and maintainability, but often trades early clarity for ceremony when applied indiscriminately.

User-centric design

Design from the outside in: start with what the user needs to see and do, build the minimal interfaces to support it, and then backfill logic and data.

It optimizes for value and feedback speed rather than technical purity.