What is technical debt?
“[Technical Debt is] everything that stops you from effectively adding new features to your software product”. That might be duplicated code, poor or missing design or even an improper technical decision such as ‘We are going to use the xyz-framework here’.
Where duplication being the most common of them all. Either in the form of cut-n-pasted code or more hard to spot duplication in missing or incorrect abstractions.
How does it come up then?
There are several reasons code bases accumulate technical debt. One very common reason is stress. Stress put on a software team by, for instance, a product owner who believes that new features should or could be produced faster. Or it might be from a project manager that wants to adhere to a deadline put on the project by an eager overselling organization. There are probably close to an infinite amount of reasons why software teams can be or will be stressed now and in the future.
The lack of proper information is another reason that will bring a software development effort to its knees quickly by building up technical debt. Pieces of information which gets lost between the wish for a new feature and its implementation. On a features trip from concept to cash, so to speak.
The lack of proper information at the proper time will lead to guessing and guessing will lead to bad design. Maybe not bad in a technical perspective. But bad from a business perspective. Which means; “Guessing leads to technical debt”.
Well, how do I pay my debts?
Tidying up software is tedious work. Removing duplication, adding documentation or speeding up tests to shorten the feedback cycle usually doesn’t rank very high on a programmers To Do-list. My best tip would be dedicating time on a regular basis to do cleaning up. Much like you do your dishes or cleaning the house. To avoid falling in the gold-plating trap, time box this. Otherwise you will have a development team that ends up spending all their time on creating ‘the perfect solution’.
And as with money, the faster you pay, the less interest you pay. This means that you should not let debt accumulate. Once a week is probably a fairly reasonable interval in paying back your software debt.
Can I pay in advance?
Shortly. No! Paying in advance is at best guessing. It can be qualified guessing, but it would still be guessing. Personally, I prefer to base my decisions on real data not guesses and with software there is no such thing as accumulating good design. You can not really accumulate (good) design and then make a withdrawal, so to speak, and your balance would be zero. Either you are in debt or you aren’t. You cannot be on ‘the positive side’.
How do I make use of a market opportunity then?
To me, hitting a market window, sounds very reactive. Deliberately putting oneself into debt might look like a valid solution at certain points. I’d say that it is a short term solution though. Making money, which it really boils down to, can be done in less reactive ways.
I prefer to be in control of a situation over acting in a reactive fashion. This leads me to make decisions in another way. Way earlier. In terms of how to produce good software, I would choose a way which allows me to deliver often, scope out or change my mind equally often and use that feedback [data] to guide my future decisions.
You might argue that a well thought through payment plan will make this work.
I say; You can’t get one.
Because you can’t know the interest! Even if you could, the fact that there is no such thing as a fixed interest in software development loans makes this a very risky affair.
So, how do you want to work?
Reactively or proactively?