No architecture is better than bad architecture

Most people agree that if you want to build a successful business, first you have to build a few failed ones.

Same thing applies to code: bad code is a required step before good code. Accepting this fact is very liberating. Quality of my code is not the measure of me as an engineer. It's how I distribute quality that's important.

I have a very similar experience to author's.

There's plenty of bad code I wrote that never got used in the end. And while it's sad it did not get used, at least I didn't waste time perfecting it.

There's plenty of bad code I wrote that is being used for years and most engineers don't even know that it's bad. Their eyes will bleed if they look at it. But they have no reason to: it just works.

There's plenty of bad code I wrote that caused pain. So I just made it better when it did. I anticipated the pain and I was ready for it.

Unfortunately most of our practices and tooling are structured around pain avoidance and reduction. But no amount of unit tests will deliver the same value to you as, let's say, Sentry.

I feel this at my current job. I’m currently tearing down a “well abstracted” api and instead exposing the underlying tables more directly because no one knows how it works and adding new features to it is a PITA. At a glance it’s a lovely api but the implementation is so full of neat magic and layer upon layer of abstractions that it’s impossible to follow what it’s actually doing.

This is no fault of the original authors, they are great devs and tried their best but even they now recognize that it’s not working out.

I still think you should write good abstractions for any large project, the thing is that they are very difficult to get right from the start. And as OP says, it’s easy to get lost in elegance-creating busy work, especially if you enjoy it.

I’m terrible at it so I always build things as barebones as I can get away with. If I try to abstract it there’s usually been a new usecase 6 months down the line that completely breaks the abstraction anyway.

Wait until a pattern emerges, "rule of three".

"But this is a rewrite of existing legacy functionally"

I came to an org that is rewriting their entire .net in kotlin, and trying to do it right.

Then came the PMs who mentioned "this legacy functionally is getting resigned, we don't need a lot of this" but by that time, the Principal Arch had already gotten his promotion and built interfaces extending interfaces and common libraries composed of common libraries, and everything is neatly pushed into its own modules, leaving 1 file per module, max hierarchy for max portability that will never happen.

The junior devs ask more questions about "where should this live" after being bitten by overarch.

There is no such thing as “no architecture”. You will always have an architecture no matter what you do. So better think about what you want the architecture to be or you will end up with the “mud pile” architecture most software has.

Maybe my experience is different to the author’s but I’ve encountered lots of unmaintainable incoherent mess and extremely little over-designed works of art.

As such the message is very unfcomfortable. It’s fundamentally saying, don’t prematurely optimise, prematurely design layers of abstraction, which is correct, but I’m not sure our industry needs to be encouraged to smash stuff together and to hell with the consequences really.

I think the thesis here is that it doesn't matter if your code is an incoherent mess if someone is paying for it anyway.

Similar to the Big Ball of Mud [0]:

>If you think good architecture is expensive, try bad architecture.

[0]: http://laputan.org/mud/