Technical debt vs. overengineering

Technical debt is a metaphor for making a technical decision, knowingly or otherwise, that works in the short term but may cause trouble in the long run. For example, your database access code is scattered throughout the application instead of living in one layer.

Overengineering means choosing an overly complicated solution to a particular problem. For example, you need to expose an XML document over HTTP and can't think of anything better than using Web Services with WS-Security.

I'd never noticed it before, but these are the two criteria or boundaries we balance between when developing software. What's interesting is that different pressures push us in each direction. Product management pushes us to deliver new features as fast as possible, indirectly encouraging us to live on technical debt. Sensible product managers know you can only do that up to a point. Our engineering pride pushes the other way, toward crystal-clear solutions that are sometimes too complicated.

Balancing technical debt and overengineering is a bit like walking a tightrope. You can easily lose your balance and fall flat on your face. There is no simple answer to whether technical debt or an unnecessarily elaborate solution is better.

An important factor is where we incur technical debt or overengineer things. It might be design, development, code or deployment. We can probably accept some technical debt in the code because, if we respect encapsulation, we can isolate the problem in one place and keep it from spreading. At the design level it is much worse, because every mistake is multiplied at each stage all the way to deployment.

I can't think of a rule of thumb beyond this: make things as simple as possible, but no simpler.

I'll add three links about technical debt to this very short reflection.

• TechnicalDebt (Martin Fowler)
• TechnicalDebtQuadrant (Martin Fowler)
• Technology Debt? Don’t bet on it.