Technical Debt

One of the publications that gives you a good overview what is happening in the world of software development is SD Times. Their parent company BZ Media conducts physical and virtual events. Todays invitation rose my interest since it was titled " A Technical Debt Roadmap". From the description:
" "Technical Debt" refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules.
Technical debt is inherently neither good nor bad: Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive. However, just as with the financial kind, it's important to know what you're getting into."
Go sign up, the speaker is Steve McConnell, the author of Code Complete . Having grown up in conservative Germany (yes I'm Bavarian) the concept of "Schulden haben" (having debt) had the stigma of failure and loose morals and I'm very concerned when looking at the required interest payments when it comes to debt. A very German engineering trait is that "things need to be done right" rather than "good enough". It is the foundation of successes like Daimler, Audi or BMW. In a nutshell it is the idea that on delivery a piece of work must be debt free. This doesn't translate very well into software, which by the nature of facts can't be debt free. So it is always a balancing act. Ever increasing complexity and growing interdependency seem to favour greater amounts of debt: "Delivery is now, the fixpack is later". However there are different kinds of debt, like in the financial world: your mortgage (hopefully) backed by an asset, your consumption loan, your credit card balance and (hopefully not) that open item from the loan shark in the casino. The equivalent in software would be (in no particular order):

• Hardcode debt: system names, maintenance passwords, URL settings etc. are fixed values in an application. Debt is due if any of these needs to be changed. Typically can be found in organisations where creation and maintenance of applications are strictly separated or the development team lacks the experience
• Broken code debt (the classical bug): something doesn't work as expected. Usually gets paid once the bug surfaces and a big enough customer complaints
• Missing feature debt: Gets paid in a following version - if there is one
• Missed expectation debt: Sales, marketing or management make promises or announcement that don't get realised in the current code stream. Close relative to the "missing feature debt". Typically that debt is met with product management denial: "How much more do I sell if I implement that?" Denial since the one who created the expectation already "spent the money" and failure to service this debt will lead to loss of repudiation, credibility, trust and ultimately customers and revenue
• Non-Functional debt: Software does what it should but misses non-functional requirements like robustness (against failure) or resillience (against attack) or integration capabilities. Expensive debt (it would call it the credit card balance of software) since the discovery of resillience flaws often leads to (expensive) emergency actions and the lack of integration capabilities leads to rewrites or addition of a lot of middleware. Also it is difficult to spot since more and more software is business funded where there is little understanding for non-functional traps
• Bad code debt: The equivalent of a loan shark arrangement. Looks OK on first view, the software works at delivery (the night in the casino wasn't disrupted by lack of funds). Usually payment is limited to parts of the interest (patch it up baby). Leads to abandoning of systems (declared bankruptcy). Typically that debt is hidden as long as possible (who wants to admit to owe to a loan shark) to then take everybody "by surprise".

Paying technical debt requires real money. It is paid back with engineering hours someone needs to pay (if you can find the right talent). As with all debt: if you only serve the interest but not the principal the debt doesn't go away and at some point the interest payments will be more than the principal. Something a myopic quarter to quarter view might overlook.