'Clean Architecture' is the most inane thing in the software engineering world

Everyone who I have seen to be a religious follower of Uncle Bob's methods, has 99% times turned out to be an extremely incompetent engineer.

When I was writing code for my own startup - without any prior experience, most things were structured fairly simply. The initial few people I had hired were also people I mentored and taught a lot of programming, and they, like me, had no prior experience at "enterprise" places, so they also wrote code fairly simply.

Then I moved to Zomato, worked on the mobile app, (which was by then itself, already fairly big - 2M+ SLoC, 30+ modules, 3 different apps built from the same major repo). One of the things lot of people lamented there was that there wasn't a lot of 'structure' to the code, avant garde architecture principles like Clean Architecture was not being followed, and a only the most recently written code was MVVM, but most of the rest wasn't. We didn't even have any dependency injection framework setup.

Then I went to work for a while at Target. An absolutely dogmatic 'enterprise' codebase. Every new feature, evern before any significant line of code was written, would first spawn 3 modules. 1 for the 'domain' code, that used to just be a bunch of interfaces, written in pure non-Android-dependent Java, 1 for the Android specifics and would implement the first module, and then a third module for all the testing code. If it required local data storage, a fourth module would get created. There were a bunch of people who would absolutely get off on writing bunch of 'adapters', 'strategies', 'factories', 'builders', and even adding a new button would generate 200 new lines of code.

Looking back at it now, Zomato used to respond to a tweet on Monday saying 'please make this', and ship it as a feature by next Wednesday release. People new to the codebase could ship code within their first 2-3 days. And despite a lot of issues (like some performance problems, memory leaks, extremely large classes that did too many things over many years), almost none were actually because it wasn't trying to make the architecture what essentially looked like peeling off layers of an onion.

At Target, new engineers would not be able to do much more than write tests, and not create new features, for as long as 2-3 months into the codebase. Features would take eons to ship. Even things which had just one possible implementation (with no possible future alternative implementations) still would have to be split up into a generic interface with a separate concrete implementations. Debugging would be a extremely painful because nothing was coupled. Clicking "see definition" or "see usages" in the IDE was mostly pointless because everything would lead to one more layer of 'indirection', and despite way more number of anal 'senior' engineers who forced everyone to write code with 5 layers of indirection, it was worse off than Zomato in every possible metric. (crash rates, memory footprint, performance, app startup, turn around time for new features, app size.... every metric)

This is not to say Zomato's codebase was a shining beacon of what large codebases should be like (it very much was not, and had its own set of reasons for being hard to deal with), it was a great lesson for me that, at least whatever was wrong, was definitely not because we were not following Clean Architecture, and not making every feature into 4 separate modules, and because we didn't have dependency injection setup.

And that's the first time I started getting convinced that 'Clean Architecture' is 100% an anti-pattern. I actually read the book end to end first time at that time (till then I only had read blogs about how Clean Architecture was implented, but not read the original Clean Code book).

Having had worked enough on production codebased, hiring and managing teams who have to work on production codebases, and seeing the real world impact of different architecture patterns, I honestly couldn't get to understand what made everyone follow Uncle Bob and his horrible book so much. Every chapter I read felt like garbage. Every 'prescription' of how to write code I saw in the book made me wonder if this famous person writing this book has every actually written code for a real production system, and worked with a real team of software engineers or not.

The truth is, most of the people who read Uncle Bob's books have written far more production code in their lives than he ever has. Most of the readers of his book have far more practical experience of working in a large modern software engineering team than he has. He has been just writing sermon after sermon on how to write more succinct classes in Java from 1995, without ever having written any real code in production. He is the classical example of college professors who have never worked in the industry. He is a senile grandpa, crying hoarse about "in my time we wrote code like this, and you kids don't know better", while the world has gone far far ahead.

It has now come to point that I use this as a litmus test for who understands good software architecture and who doesn't. And people who dogmatically try to follow any of Clean, Onion, Hexagon and all that crap, are people I absolutely steer clear of, and never discuss software engineering with ever in future.

I have never had the energy to write about how stupid Clean Code is, but someone I respect a lot has done that, and I keep just sharing the link to his article, everytime I hear any faint whispers about 'Clean Code' in any team. Sam Hughes, more famously known as the author of the SCP Foundation and Antimemetics Division, is also a programmer, and has taken out the time and effort to lay out clearly how useless most of the advise in Clean Code book is.

https://qntm.org/clean