Is Clean Architecture messy?

Pendulums swing right? At least this time they’re swinging in a direction which may actually do some good to our industry. Now, I think Robert C. Martin is a brilliant man and excellent marketeer . He no doubt has a lot of SOLID advice tangled into his Clean Code / Architecture / Agile Alliance and so on, but as with any “principle” if you follow it without questioning it, you’re likely going to end up with an unwieldy mess of a code base. If not, then kudos to you, in two decades of software engineering I’ve unfortunately never been lucky enough to see such a unicorn. What is perhaps the thing I dislike about the man behind it all is how “Uncle Bob” responds to criticism. Maybe that’s just like my opinion man, but if you’re curious just go and have a look at his personal “blog”. I recently read his response to Daniel Terhorst-North’s, in my opinion constructive, feed back on Clean Architecture and SOLID and it’s outright vile and nasty. Which isn’t too uncommon in the usenet generation of IT gurus, but even if you ignore this, a lot of the responses can basically be boiled down to “they completely misunderstood my principles”. To be fair, I think he’s often correct, but I think the problem is with the principles rather than the people who try to understand them. Partly because the principles are vague to a degree that is perhaps convenient if you’re in the business of selling consulting on said principles?

Now what was surprising to me as I looked into “Uncle Bob” was perhaps that the author behind Clean Code, Clean Architecture, The Clean Coder and even what I consider to be outdated books like Agile Principles and Patterns in C# and UML in JAVA. Is that he last worked professionally in actual Software Engineering a good 15-20 years before Python was even Invented. That’s right… The guy behind Clean * last did professional programming when Fortran was the most used Language in our Industry. So perhaps it’s not surprising that a lot of the principles aren’t working out so well here a good 20 years after they were written. I think it’s important for me to remind you that I think every principles, and every book I’ve read, has a lot of good points. The major issue I have with Clean is more along the lines of how “Uncle Bob” hasn’t exactly updated them to fit the criticism and research in Software Engineering from people who have actually followed them. Anyway, let’s dig into some of the criticism I think is on point.

Single responsibility

No doubt my favourite of the SOLID principles. Now to paraphrase “Uncle Bob” himself, he points out that this is the most misunderstood principles and admits that its name is a bit misleading. In his own words: SRP says that a class or a method should have only one reason to change. Which is still hilariously vague in my opinion, but if you’ve actually read his works and not just picked up on SOLID from the internet you’ll know it also tells you that the higher level of abstraction the less detail you’re supposed to include. What I think is perhaps the most common misunderstanding is that it perhaps should have been named “DON’T MIX LEVELS OF ABSTRACTION” rather than “single responsibility”. In none of his works “Uncle Bob” ever explains how you’re supposed to separate your portfolio from your assets; how you’re supposed to separate your assets from your computation and so on. As such it’s an easy principle to get wrong.

Even if you do get it right it still comes with a cost. What you give up is locality of behaviour, which is understanding what is going on with a piece of code you’re looking at without having to jump around to 5 different files in 3 different projects. So the trade off here is that the more you abstract the more you give up your locality of behaviour, making things unwieldy and actually also harder to test. Well functionally test, it makes it easier to put in a lot of needless tests which basically always go green because you’re testing your assets rather than what the business needs. When you then get the principle wrong you’ll likely end up with over-abstraction. To put it more plainly, the principle is about a bicycle. I like using a bicycle as an example because you very likely know exactly how every part works, but the point of the single responsibility is that you actually don’t need to know how crank arm rotation connects with chain movement or how chain transfer works with rear gear rotation and so on. What you may be doing when you get the principle wrong is that you’re putting in abstractions between the steps, but even if you get it right, you’re putting the four things in completely different places. Which may be fine with four things, but to generate forward motion with a bicycle you’re at least 7 abstractions. Now when you need to create a unicycle… Well… Good luck with your variability problem.

Last but not least people tend to over complicate their code before they need it. In my personal opinion any good programming book should print “don’t abstract until you have no other option”. This is because you’re simply going to have far more productive code if you go concrete until you need an abstraction or an interface. If your interface is only consumed once and your adaptor only does one thing, then you’ve just build three things you need to maintain for absolutely no reason other than you’ve been taught in school that good code looks like that. It doesn’t, your teacher lied to you. It probably wasn’t intentional, because there is a very good chance that your teacher has never actually worked on a code base 5 years after it made it into production. There is also a very good chance that your teacher was subject to the absolute unit of a marketing machine that is “Uncle Bob” and the ocean of consultants who preach his works. Consultants which similar to your teacher and the man himself probably aren’t software engineers by trade but are instead paddlers of consulting that you pay money when you don’t understand why your code is horrible.

DRY

Another cool concept is that you should never repeat yourself. This is good advice for the most part, but as with any principle it isn’t free. With DRY you trade the ability to change requirements for reduce duplication. Typically this will be a very good trade for the programmer and a horrible trade for the business which pays the programmer to implement changes. You know this principle as a “Bird” or a “Car” or whatever abstraction you were taught. It works well when you have a duck, an ostrich and an eagle and only do the “fly”, “swim”, “run” part. What happens when you add “dive”? This is perhaps easy for the duck, but what about the eagle? Now you’ll need to add swoop. Then you’re adding behaviours such as nesting, eating, hunting and so on. How do you think your CLEAN code looks now?

In all likelihood it looks extremely messy. Especially if “you” was really ten people working on “Animal” as the top level abstraction over a period of five years. How rapidly do you think you could add a penguin, having to modify all those abstractions and their tests? If you duplicated your code and separated it by functionality, adding a penguin would be as easy as adding your first bird. Which is what your business cares about. Which is what, you, should care about because you’re in a service function and your sole existing is adding more business value than you cost. Yes you’ve likely build different versions of “swim” because a penguin and a duck don’t swim the same way, but how often does the way a penguin swim really change?

I could go on forever about how CLEAN is actually MESSY, but I think you’ve gotten the gist of my opinion on the matter. This wasn’t an easy opinion to form, it took me 20 years and I can assure you that it followed the five stages of grief. At first I didn’t want to believe that the foundation of my CS degree was wrong… I’m perpetually stuck with the frustration, however, because I have a side gig as an external examiner for CS students. Students who are, still, taught the same curriculum I was. As you can imagine it pains me to examine students on subjects that I know are both wrong and outdated as the pendulum swings.

YAGNI

You aren’t going to need it! Go pure concrete until you need that interface. Don’t abstract unless you, have, to! Now that was like my opinion man, as I pointed out from the very beginning, but what is yours?