Developers are often frustrated over technical debt. Me too.
I realise the power of new technology, cloud scalability, platform and device independent clients, and event-driven solutions. But I also love to work with new technology. I would rather travel through Europe in a Mercedes than a flower power Camper from 1968, if you know what I mean.
But we can’t always live our dream, and it is important to understand technical debt from a business perspective. So, therefore: Is technical debt handled as financial debt by the finance people at the company? Is the management aware that their loved and bespoke system might look like a plumbers nightmare behind the glorious outside? Let’s find out!
What is technical debt?
The term technical debt has been widely used to describe that bad code is actually costing a company something. It’s a way to express that when developers have to decrease quality of code to deliver faster, the cost for doing the code right is moved to the future. The cost does not disappear, it’s still there and most likely growing.
Ward Cunningham, one of the authors of the Agile Manifesto, once said that some problems with code are like financial debt. It’s OK to borrow against the future, as long as you pay it off.
There is also another view of technical debt: Since the system was built, a lot has happened around the world of IT. By doing nothing to adjust the system to the new reality, a technical debt has grown. The technical limitations hinder the company from expanding and evolving the business.
If you want to get deeper into technical debt and ageing systems, please have a look at this article: Technical debt and ageing systems.
“Debt makes sense when today’s borrowing will lead to a better tomorrow” – Erik Frederick
How do we talk about systems in financial terms?
How are systems and systems development defined in financial terms?
- Systems are assets that are generally valued from a sales and market perspective.
- Adding and improving features is considered investments. Investments will increase the value of the asset, the system.
- Over time there are deprecations that make the asset’s value decrease.
- Maintenance is considered as a cost.
Are companies aware of their technical debt?
The technical debt should affect the value of the asset and might be rejected by the deprecations. It’s not so easy to calculate the value of a system since there are new features added to one part of it, at the same time as the technical debt grows in another. Or rather, everything is nestled together and hard to overview. My impression, though, is that many companies are unaware of their technical debt. The reasons for that might be:
- The developers and business analysts that work with the system have grown together with it, and so have the customers. They have all built their careers on it, and their knowledge about other things may be limited. Their willingness and ability to change may be as low as the old system’s possibilities to change.
- Management and product owners don’t know so much about technology, and technology loving developers and architects are sometimes acting in their own interest. There is a lack of trust and the very important discussion about technical debt is avoided.
Technical vs. Financial debt
Fortunately, I’m not the first one who has asked myself the question about how to position technical vs financial debt:
Erik Frederick, a finance expert, reacts upon technical debts as follows: “With financial debt, there are usually credit committees, asset and liability management teams, and treasury staff that monitor levels like a hawk. With technical debt, however, very few of these controls exist in traditional businesses.”
Just like financial debts, technical debts are rarely paid off. As soon as you write new code, it starts to age, and the technical debt starts growing. For both types of debts, the challenge is to find the strategically right level of debt. I write more about that in my article referred to above.
So, is technical debt a financial debt?
Based on what Erik Frederick writes, a technical debt does not necessarily have to be the same thing as financial debt. The financial debt is something that you owe external parts and therefore is more formally handled. The technical debt is internal and more abstract and something that is not really visible in the books. It’s something you owe yourself. It is part of the company value though, and I suppose (hope) few companies acquire a company without reviewing the tech stack first.
“As with financial debt, in order to manage your technical debt liabilities, you first need to know what they are, how much they are, and their payment terms.” – Erik Frederick
Conclusion
We have concluded that financial debt and technical debt cannot be considered the same thing, and that one of the differences is how they are handled formally. But, isn’t their magnitude for the company equal?
I think that companies should take their technical debt more seriously. Many company owners seem so happily unaware about their ageing systems, and the problems can come fast. There are examples like Nokia, that couldn’t survive the arrival of the smartphone, and Hasselblad, the camera manufacturer that couldn’t do the transfer to digital cameras. This could happen to your company too.
On the other hand, I have to admit that there are many very successful companies out there, with products written in old technologies like Delphi or Cobol. Both banks and car companies, and others. They have learned to balance their technical debt according to business demands, risk and finance. Or, at least they do it better than their competitors!
What do you think?
I’m very curious to hear how you handle your technical debt financially! Many of you are tech leaders in a wide range of London companies. How do you evaluate and calculate your technical debt?
If you want to read more about this:
Finally, if you liked this, take a look at my blog.