Recently I was playing around with the following question:
Is it easier to fix underengineering in a codebase or overengineering?
This question naively assumes that there is a "right" level of engineering, which makes maintenance and enhancements most efficient. In reality, of course, this level depends on the requirements, expected future of the project, company culture, etc. But let's just pretend there is such an ideal, non-subjective, level.
Let's also pretend we all have some similar understanding of what both terms mean.
Underengineering might have the following ingredients:
- too few abstractions
- entangled concerns (non-SOLID code)
- spaghetti
Overengineering might consist of the following:
- too many abstractions
- consequently, very deep call stacks
- violating the YAGNI principle
While talking to people about this, I heard different opinions, many of them, naturally, including an "it depends", but I found the analogy my colleague Benjamin (CPO, former CTO, former ingenious software developer) spontaneously came up with especially striking, so I'd like to present it here. 🙂
Fixing underengineering is like solving a jigsaw puzzle. It's easy in the small, but the complexity grows exponentially with the number of pieces.
Fixing overengineering is removing superfluous abstractions. It scales linearly with the size.
Thus, for small projects, underengineering might be easier to fix, but once the project grows in size, overengineering is less troublesome to fix later. (Of course, the initial cost to develop the overengineered solution might be somewhat higher, but that's not the concern of this article. 😉)