Debt in IT and Software Development (via: Coding Horror: Paying Down Your Technical Debt)
Posted by jpluimers on 2012/04/04
Thanks to Randy Glasbergen for the debt image
I love this quote from Jeff Attwood on technical debt in 2009:
periodically pay down your technical debt
and the Computer Weekely article about half a year ago:
Short-term speed may come at the price of long-term delays and cost.
Lately, I find that I need to explain Debt in relation to IT and Software Development more and more often.
We now all know what happens with the financial system when we let debt get out of control.
The same holds for your IT and Software Development.
Debts get introduced by not “playing by the rules”. The quotes are there because you can not always play nicely, and the rules are not always clear or known.
Lets give a few examples of rules that – from experience at clients – are more often than not neglected. The examples are based on Windows, but could just as easily be Mac OS X, Unix, OS/400 or anything else.
- Make sure you use a recent Windows version
I often see companies lagging more than one version behind (i.e. still use Windows XP or SQL Server 2000). That’s too far. - Don’t run your users with too many privileges (and certainly not as Administrators)
Especially running as Administrator will get you in trouble with User Account Control (UAC) in Windows Vista and up. - Using directories like C:\TEMP is a no-no.
This should be a no-brainer, but truckloads of in-company software still thinks it can write everywhere.
I know C:\TEMP used to be the Temporary Folder some 20 years ago.
But that was then, and this is now: Use the %TEMP% environment variable or GetTempPath function (even better: the GetTempFileName function or the .NET Path.GetTempFileName function).
More in general for known folders, use CSIDL or KNOWNFOLDERID whenever possible. Your favourite development tool usually has a library functions for that, for instance the .NET System.Environment.GetFolderPath function.
These few were examples ranged from technically very broad to specific. There are more, but these will give you a rough idea how wide the field of debt can be. Even debt outside the realm of Technical Debt can turn out to be really expensive.
Every time you postpone or skip a Windows version, you collect some debt in the hope (often wrongfully called expectation) that you earn more on the money/resource you just didn’t invest and putting that money/resource to use otherwise. The same holds for any other kind of debt.
The main problem with debt is not the total of the debt, it is the interest rate that makes the accrued debt grows faster than most people and organizations realize.
This is actually one of the main causes of the current world wide financial crisis, the same holds for many IT debts.
And for all kinds of debts, you often don’t know how high the interest rate will be, so the accrued value can be way beyond what you expect.
I’ve regularly seen projects collecting so much debt, that migration costs raised to thousands of hours because of it, resulting into management taking another very bad decision: rewriting the stuff from scratch. Don’t do that: Joel on Software excellently describes what happens when you do that.
What to do about it?
You might say “don’t collect debt”, but you can’t always avoid debt.
So you need to build periods where you pay off accrued debt. And you need to do that regularly, in order to avoid the interest pitfall.
This does not limit itself to software development (though that’s what I normally focus at). It covers a wide range of IT topics.
Sometimes, you can even pay your debt in advance. For instance, I was among the first to switch from Windows XP to the x64 of Windows Vista. I knew it would cause pain, but it immediately payed back by being able to use much more memory, and run more Virtual Machines at the same time. That made me more flexible and productive.
–jeroen
via: Coding Horror: Paying Down Your Technical Debt.
The Wiert Corner - irregular stream of stuff 
Reminiscence of the past: Delphi I/O error 131 « The Wiert Corner – irregular stream of stuff said
[…] instance where technical debt in IT raises its ugly head and the compound interest is really […]
Unicode in Windows (Delphi, .NET, APIs, etc) - .NET Code Geeks said
[…] Of course remnants from the past will catch up with you: if you have Technical Debton the past where characters were bytes, and you abused Char/PChar/array-of-char/etc you need to fix […]
IL said
Managing Technical Debt by Eric Allman (March 23, 2012)
http://queue.acm.org/detail.cfm?id=2168798
Comparison with financial debt.
jpluimers said
Thanks! Very interesting.
WarrenP said
Technical debt exists mostly where you can’t see it, until it stops you dead in your tracks. An external dependency on a hard-coded path (C:\TEMP, or any hard coded path, anywhere) is technical debt of the very nicest kind because you can see it, and you know about it. The kind of technical debt that is most crippling is (for example) when someone does a date-math hack that breaks on leap days (such as the bugs that brought down Microsoft’s Azure servers recently). Now that’s some killer technical debt.
I routinely see people on StackOverflow who don’t want to upgrade their Delphi codebase to work in unicode, don’t want to leave behind Windows XP, and who think that any working system (however barely functional it is) takes precedence over any kind of risk. It’s those people who pilot their ships into reefs that they themselves have created. Fear leads to paralysis, and paralysis leads to self-destruction. I think that along with technical debt, there is some psychology of learning-the-wrong-lessons that leads to people who are really otherwise quite smart, making disastrous decisions.
In the end, it’s a problem between the keyboard and the chair.
Warren
Some words on Unicode in Windows (Delphi, .NET, APIs, etc) « The Wiert Corner – irregular stream of Wiert stuff said
[…] Comments ldsandon on Debt in IT and Software Develo…rloveutah on Debt in IT and Software Develo…Darren Davis on Debt in IT and Software […]
rloveutah said
Totally agree. Every agile sprint we try to remove as much technical debt as possible in the areas touched by the sprint. This included both bugs, and design flaws.
Darren Davis said
It’s one of those key job (worth) indicators.
When you find that the technical debts you raise into the bug list / road map etc., keep getting removed, it’s time to leave. This generally happens as technical debts don’t often have business owners, so no one will sign off the “job”. In financial terms what then happens is that you’re constantly paying interest but never paying the principle.
ldsandon said
It’s also a key indicator of when a developer is past its time. Developers who accumulate debts in their code need a strong incentive to pay them, or a strong inventive to find a job elsewhere.