The SOLID Edition
SOLID is pretty old now. Are there newer alternatives that are more relevant? Let's examine three.
SOLID was invented by Uncle Bob Martin. It’s a backronym.
The author started with the letters and reverse engineered words to fit them.
There are many critiques out there.
Kevlin Henney’s The SOLID Design Principles Deconstructed is a good place to start.
In this newsletter we’ll examine three alternatives.
Four Rules of Simple Design - Kent Beck
SHOC - Jason Gorman
CUPID - Dan North
1. Four Rules of Simple Design
It's shocking how few engineers have heard of this.
And yet it's one of the best ways I know of evolving a design.
Simple code adheres to all four rules.
Rule 1. The code works.
Rule 2. The code expresses intent
Rule 3. The code has no duplication (including ideas)
Rule 4. The code has no dead parts
We go through the rules sequentially.
We don't go onto the next rule until the previous rule has been satisfied.
Rule 1. The code works
Note it doesn't say "passes all the tests".
Tests can be misleading, depending on how they're written.
Make sure the code works and there are no edge cases that you're aware of.
Rule 2. The code expresses intent.
Put another way - good names.
Read the code literally line by line.
Does every line make sense?
Does it read like English?
Adjust the names until it does.
Rule 3. The code has no duplication.
There are no pieces of code that are duplicated.
This also applies to duplication of ideas.
If there's a similar thing expressed elsewhere but the code is different...
...that's still duplication.
Eliminate it.
Rule 4. The code has no dead parts
Debatably, this is the easiest rule to verify.
There's no unused code.
So in summary:
Rule 1. The code works.
Rule 2. The code expresses intent
Rule 3. The code has no duplication (including ideas)
Rule 4. The code has no dead parts
I've found following these four rules pivotal in building software that's well designed.
2. SHOC
Invented by Jason Gorman
See this SHOC video where he outlines the principles.
* Swappable
* Hides internal workings
* One job
* Client driven interfaces
I find this a much better alternative:
* Easier to understand
* Applies to modules, not just classes
* Plain English
3. CUPID
Invented by Dan North.
He introduces CUPID in this blog post.
Composable: plays well with others
Unix philosophy: does one thing well
Predictable: does what you expect
Idiomatic: feels natural
Domain-based: the solution domain models the problem domain in language and structure
CUPID is about finding joy in coding again.
Instead of making the codebase “habitable”, Dan says we can and should shoot much higher.
Let’s make finding defects and adding features joyful!
He also says code that fits in your head is an important metric.
There’s been a lot of pushback from the community.
Personally I think Dan’s really onto something.
I’ve found myself building non idiomatic castles in the sky to try to make code that’s easy to change.
Others find this kind of code difficult to work with and understand.
How can we make software that’s easy to change and joyful to work with?
Only by breaking things apart and creating the right kind of abstractions.
Summary
So there you have it. Three alternatives to SOLID.
Which do I use?
I think all three have their merits.
I’ll give the last word to Denis Cahuk based off his excellent comment:
I don't think these acronyms are a good substitute for education if the acronym (and the underlying meanings) don't simply express principles and patterns.
The S in solid stands for SRP. Who can explain the S in SRP so that we understand a 5th of SOLID.
The L in SOLID stands for LSP. The L stands for Liskov, as in Barbara Liskov. She is still alive. Did anyone watch any of her talks on LSP?
The D in SOLID stands for DIP. That's DI for dependency inversion (principle). That doesn't mean you're using an autowire container, the emphasis is on inverting responsibilities and call-stack hierarchies.
All this information is public and easy to google. Yet after 10-15 years in the industry I still have to look them up because they simply don't make sense and never did.
SOLID was invented to sell a book about Clean Code and Architecture. It was very successful in that. However, it isn't a very successful no-brainer for developers who didn't have the opportunity to work in a great team and have real, tangible problems beyond the ability to adopt SOLID or Clean Architecture.
If you’ve not subscribed to Denis’ excellent Crafting Tech Teams, give it a shot. It’s chock full of interesting information!
What Next?
I have two options:
Book a 1 hour coaching session (normally $200, FREE for a limited time)
Buy Software Design Simplified - an introduction for curious, driven engineers
Have a great week!