Creating the perfect software
As a product owner of a software system, in order to reach your business goals, probably your focus is to implement as many features as you can in the least possible amount of time.
At the beginning of the project, everything goes well and smoothly. You might even release your MVP ahead of schedule and make your customers are happy. Great!
But then the velocity of the development team drops. After the MVP’s release the number of bugs increases. Seemingly out of nowhere you’re faced with a demotivated development team.
Probably, you are dealing with technical debt.
The definition of technical debt according to Wikipedia reads as follows:
“Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.”
Maybe this sounds a bit vague or abstract so let me explain this with a metaphor. When you borrow money, you can do something sooner than you might be able to do otherwise. But until you've paid back the loan you’ll be paying interest. If you choose not to repay your loan, you'll keep on paying interest until you are out of money and reach bankruptcy.
Kinds of technical debts
Technical debt is the same, you take a loan on quality. You choose an easy solution to rush things out of the door. Maybe because you want to get some real-world experience with a solution first, or maybe you are faced with a deadline. If you do not take the time to repay your technical debt, you eventually reach technical bankruptcy.
This example is called “Deliberate tech debt”. Provided it is addressed properly, deliberate tech debt is not necessarily a bad thing. Creating software is a complex thing, sometimes you cannot know upfront what the best solution will be until it is tested in the wild (a.k.a. production).
There are other types of technical debt that just arise like “accidental/outdated design tech debt”. As systems evolve and requirements change, you might realize one day that your design is flawed, or that new functionality is difficult to implement.
The software industry is evolving extremely fast and we cannot predict the future. Something that sounds like a good idea today, can turn against you tomorrow. It is completely natural to significantly refactor a system every now and then. Team leads and product owners should take this kind of debt into account, and reserve some time to resolve this accidental/outdated design tech debt.
Another type of debt is “Bit rot tech debt”. This slowly happens over time. Developers come and go, and not everyone fully understands the original design of the system. This type of technical debt is something we try to avoid. It's the bad type of technical debt.
How to avoid technical bankruptcy?
At the moment you decide to build a quick solution to get your MVP out of the door, you have to reserve some time in the future. This will enable you to implement a better solution. Put an item on the backlog and make sure this backlog item is put into a sprint so the development team can repay this technical debt.
As a developer, it is your duty to put an item on the backlog when you encounter technical debt. Making technical debt visible is essential to repay it.
These rules look simple, but repaying technical debt is not always as simple. From a business perspective, it takes a lot of time. And in the best-case scenario, the application is doing exactly what it did before. It looks like there is no added value for the business but in the long run, you will see that the quality of the software will remain high, the number of bugs stays low, and you are able to implement the features your customers are asking for.
Last, but not least; resolving bad parts of the codebase make sure developers stay happy, and everyone knows, happy developers, make better software.