Is it possible to avoid technical debt when starting a new project? And if not, should we just give up? Or can we find a way of maintaining quality projects while delivering business value at a constant pace?
On Technical Debt
If you’re unfamiliar with the concept, you can read about technical debt first. In short, it’s the cost that you will have to pay later because you’re choosing a technical solution that is cheaper to implement now. It’s like you’re taking a loan that you will pay off later.
Planned Technical Debt
Technical debt can be a conscious decision, like a real loan. It can make sense to incur technical debt. For example, if you need to find out if a certain feature will be used and is worth developing further. In that case, you might want to implement a minimal version quickly, to measure the interest. If it’s popular, you can pay off the technical debt by implementing it better and then expanding the feature.
This is planned or intentional technical debt.
Unintentional Technical Debt
But in software it can often take some time before we even realize we’ve taken the loan. We can end up in a situation where we recognize our code isn’t ideal. We’ve incurred technical debt, without realizing so.
This is unintentional technical debt. It’s almost unavoidable because the world of software development evolves so fast, and because our requirements and standards change over time.
Keep Technical Debt In Mind
So technical debt can’t be avoided. If it can, I have yet to see such a project.
But if it can’t be avoided, what’s the next best thing to do? Well, any company that’s serious about software development should acknowledge this fact, and take it into account in your process.
This means not trying to get the perfect design from the start. This can lead to over-engineering, lost time and money, and a harder time making changes later.
This doesn’t mean we shouldn’t pay attention to quality and detail. A well-crafted piece of code isn’t a piece of code that is right immediately. It’s a piece of code that can easily be changed. If it’s right immediately, but can’t be changed easily, you’ll encounter problems later on. Because all software has to change eventually.
If the software isn’t doing the correct thing, but can easily be changed, you can evolve it so that it keeps up with changing requirements.
So you should aim for faster feedback and leave room for paying off the technical debt which you’re sure you will build up. This also means allowing for time to pay off the technical debt.
Give the team time to continuously improve the code. If you don’t allow for this, technical debt can become too large to pay off, team morale will suffer, and so will productivity.
The post Avoiding Technical Debt appeared first on Red Star IT - Helping Managers Tackle Legacy Code.
Oldest comments (0)