Dr. Neil's Notes
Software > Development
Debt Collection
Introduction
Every successful product carries debt. The moment you start shipping a product to customers, you are creating debt. If the product succeeds it will need to be maintained, and supported, for a period of time, even if you release newer versions, the old versions will not vanish. Code I wrote at the end of the 1980's is likely still running somewhere, on some machine, in a system that is being supported by someone. Sorry, not sorry.
Leaving garbage on the floor
When you are at home, or your work place, and you see some garbage on the floor, a discarded wrapper, or an empty drink can, do you leave it there? Do you pick it up and throw it in the recycling? Do you expect someone else to deal with that?
If you are the person that picks it up and deals with it when you see it, then you will have less work (less debt) when you clean the house (or workplace).
If you expect someone else to deal with it, then you are following the SEP principle. SEP stands for Someone Else's Problem, this is common in the work place, hopefully less common at home. Once you have SEP, you have debt mounting up. As with financial debt, the faster the debt is cleared, the less interest you need to pay on it.
Paying Interest
With product (or technical) debt, the interest comes in several forms. Some of the interest payments will make the debt grow faster. For example to add a new feature to an existing product might require considerable rework of the existing product. To avoid that rework a clever hack is found, and still get the desired outcome. These hacks often create more debt as they compound. The product becomes a collection of duct tape and string holding things together to make things work. The cost to remove the hacks, and get the work done properly, is now higher.
Interest will need to be paid for any product that requires security. Most software products require security, as they need to connect to networks to operate, and that connection needs to be secure. Security is an area that needs constant attention, what was secure 2 years ago is less secure today, and likely not secure at all in five years.
As a product ages the tools used to build it will age, if the product is not updated to work with modern tooling, then the interest payments come in the form of slower builds, and slower run-times, than you would get from more modern tooling. The distance of a product from the latest development tools is another form of interest being charged on the debt.
So what?
Many products (especially software) are held together by this continual patching and hacking, to keep things working. It still works, people even pay for it, so what is the big deal? The value of most software products is based on where they can go next. Software that stagnates will fall out of favour, and eventually will be insecure, or fail to even load on modern operating systems.
If you want people to keep using your product you need to keep updating it. To keep updating it gets more and more expensive when you have less robust architecture underpinning the product. Each time you walk past something broken in the code, you are ignoring the increasing debt.
As a product ages, you still need to maintain it, support it, and enhance it. That work requires people to do the maintenance, support, and enhancements. The longer the product is around, the older the core code base, and the tooling used to build it, the harder it will be to hire people that have the skills to work on the product, or want to work on the product. The interest payment now comes in in increased cost of doing the work to move the product forward.
Clean as you go
The solution is to clean as you go, when you see garbage on the floor, pick it up and deal with it, immediately. This will reduce the technical debt, and the interest payments. The longer you leave the debt, the harder the work to remove the debt. Spending the time to do the rework that enables the product to maintain a robust architecture, will make the next enhancement easier, and cheaper. Keeping the product updated to work with the latest technologies and tools, will take less work than attempting to update after skipping several versions. The distance between each language, and tooling update is always smaller, and therefore less work, than when waiting to upgrade the product after skipping multiple versions.
In a large code base, when you find something that can be updated, or fixed, fix it, and also fix all the other things that have the same issue.
For example, you discover a control being used has a new version available. You want to use that new version for a feature you are working on. First update all the uses of that control in the code, not only the one where you want the new features. If you do not do this, the code will end up with several different versions of the same control being used, this is debt with plenty of interest payments. When you update one thing, update all the 'same' things.
Created: October 23, 2022 00:39:47