When it’s not over-architecting

There is a lot of push-back lately against over-architecting and too-early-abstraction. I think this is great, “DRY” often leads to bad architectures.

However, I feel it can be harmful if we don’t decide when exactly a thing is “over-architected” or “abstracted too early”. If we don’t take the time to decide, it just gives us an easy excuse to write sloppy code. “YAGNI” gets used as a cop-out.

Secondly, we have to acknowledge how difficult it is to actually go and change code that’s already out and running in production. It’s very hard! It’s easy to have good intentions to go and refactor things later when it’s necessary (eg. “we’ll extract this component once it’s used three times”), but I’ve seen old un-ideal code linger in production for months and years after it was decided that “yes, this code is a good candidate to be made more dry”. In that time people leave the company and the ideal code vision never sees the light of day. The only thing that remains indefinitely is the sloppy un-ideal solution.

So how does one identify “over-architecting”?

Here is what I believe. It’s over-architecting when adding complexity to code in order to…

• Cater for scenarios that will probably never happen. Eg. Switching to a different database.
• Optimize for performance where performance is not really critical.
• Make code super DRY, but as a result making code more difficult to follow/debug.
• Decouple code to such a degree that you can’t figure out how code will execute without attaching a debugger to see.

So, what are the exceptions? When is adding complexity to code NOT over engineering?

• When it makes code more flexible (some complexity within reason is ok).
• When it makes code more testable.
• When it sets you up for success (eg. Making it harder to do “bad” things)