Why I Stopped Using 'Clean Code' as a Religion
A pragmatic look at software development: why hyper-focusing on DRY principles and extreme abstraction often leads to worse code.
Early in my career, I read "Clean Code" and treated it like gospel doctrine. Every repeated line of code was a sin. Every function over 10 lines was a failure. I abstracted everything into perfectly decoupled, single-responsibility interfaces.
And the result? The code became almost entirely unreadable. To understand what a single feature did, you had to jump through six different files, trace a labyrinth of dependency injections, and decipher massively generic class names.
The DRY Trap
"Don't Repeat Yourself" (DRY) is the most misunderstood principle in software engineering.
We often see two pieces of code that happen to look similar right now, and we aggressively combine them into a single abstraction. But over time, the business requirements for those two features diverge. Instead of un-merging them, we start adding boolean flags. isSpecialCase, shouldOverrideBehavior... suddenly our "clean" abstraction is a chaotic mess of conditional logic.
Sometimes, duplication is far cheaper than the wrong abstraction.
Optimize for Readability and Delete-ability
I now optimize for two things:
- Linear Readability: Can a new developer sit down and read the code top-to-bottom and understand the business logic? If they have to constantly jump around to understand the control flow, the abstraction failed.
- Delete-ability: When a feature is retired, how easy is it to rip out the code? High abstraction usually means heavy coupling. If you can delete a folder and the feature is gone, you've written good code.
Write simple, obvious code. Don't build generic solutions for highly specific problems. Only abstract when the pain of duplication actually hurts.