7 Ways To Avoid Technical Debt

We all know technical debt is bad. It’s ugly, it slows development, it makes onboarding new developers more difficult and is the cause of poor performance and security holes. It must be avoided and eliminated at all costs. Here’s how:

1. Always design your architecture to be as flexible as possible. To avoid having code that’s no longer appropriate later you should write code that is generic. You can defer decision making indefinitely.
2. Avoid third party libraries. Other peoples’ code might not suit your purpose — there might be a mismatch between your needs and their implementation, which is a form of technical debt. If you build everything specific to your problem domain then you will have exactly the right code, no more, no less.
3. Don’t start coding until you’ve fully designed your whole system. If you don’t know how the whole system will work and fit together the code you write might turn out to be redundant or wrong. Avoid wasting time accruing and then paying down this technical debt by completing a detailed design first.
4. Prioritize code quality over product quality. Remember your product is made of code, so the first thing to worry about is the code. Maybe those bugs will just go away if you refactor the back-end. Cleanliness is next to godliness. Paying down your technical debt has to come before anything else.
5. One size fits all. There are so many programming languages, databases and deployment models to choose from these days that it can be tempting to adopt different technologies for different parts of your stack. This is an easy way to increase your technical debt. Now you have 3 build systems, 5 programming languages and 2 databases. Keep things simple and consistent by choosing lowest common denominator technologies that can be used across your stack, regardless of their appropriateness.
6. Experiments are for scientists. You’re not a scientist — you’re an architect and an engineer. You’ve designed your architecture so just go and build it. Trying out different approaches to a problem will litter your codebase with the technical debt of failed experiments. Stick to the architecture, the code, the design doc you already have.
7. Stick to your guns. You’re the visionary here. If your users don’t like the product then you need to find different users. Changing the product will either mean redesigning and rewriting your system from scratch or taking on significant technical debt as you rework what you have to the new requirements. Worse, it would mean accepting that you were wrong.

These are just my top seven tips. Post your own in the comments!