Rest in Peace, Technical Debt. It’s Time Forget Past Sins.
Everyone worries too much about “technical debt.”??It’s not real.??It’s just a slate of software projects that would have happened anyway.??CIOs use debt use to protect budgets with categories everyone seems to accept.??But the definition of technical debt should be retired and replaced with new projects that fix, modernize or replace applications already deployed.??Or just avoid debt with smart development decisions even when there’s no time, money or talent.??Or just forget about it altogether and focus on strategic alignment whatever that looks like.
What is Technical Debt?
Let’s start with what everyone thinks about technical debt.??For example,?ProductPlan?defines?debt this way:
“Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored.??In other words, it’s the result of prioritizing speedy delivery over perfect code.”
There are all kinds of technical debt, including:
Process debt?– Usually generated when processes are poor or lacking altogether to handle defects, documentation, or even tests.”
According to TechTarget,?there?are?different causes of debt:??
Anything new here???Aren’t these lists perpetual???Don’t they apply to every technology project we undertake???Isn’t modernization a fact of application/product life???Don’t we replace applications that can no longer be modernized???Don’t we imagine new applications and products that can capture market share?
Debt in Practice
Let’s assume that you design a house.??You determine the size you want, the number of bedrooms and bathrooms you need, and the size and features of the kitchen you’d love to have.??But you don’t have enough money for everything you want.??What do you do???You build the house and you save enough money to change the house over some period of time.??
You end up adding a bedroom, a bathroom and you redo the kitchen.??It may take you several years to get all this work done, and by that time you might even want to redo the renovations you’ve already performed.??When you bought the house should all of these projects, as well as some you never even imagined, be defined as acquisition debt???Could you have budgeted for the projects – some of which were unknown???Could you have priced them out, even though you know they wouldn’t happen until you owned the house for a few years, even as you redefined the projects on the fly?
Could you have anticipated problems with the house???Like a leaky roof, or a weak foundation???What about when the electrical system – which passed inspection when it was sold to you – caused a fire???Or when the plumbing caused a leak???Could you have anticipated these problems???Could you have estimated cost of these problems even though you had no idea what they might be or when they might occur?
领英推荐
“We take on technical debt for reasons similar to why we take on financial debt: We need something now (or very soon) that we don’t have the ‘cash’ to pay for in full.??So we borrow to get what we need.??With software, this generally means making coding or design decisions that are sub-optimal – or that we know will need to be addressed and updated in the future – in order to get what we want or need into production sooner.”
Doesn’t this analysis hold for just about everything???What doesn’t incur “debt” if it’s defined around remediation, modernization and transformation?
Costs
“Engineers?spend 33% of their time?dealing with technical debt.??Multiple studies?estimate the average organization wastes 23%-42% of their development time on technical debt.??In those same studies, CIOs reported that 10%-20% of their new product technology budget is actually spent on resolving existing issues related to tech debt.
“Gartner?predicts, ‘through 2023, I&O leaders who actively manage and reduce technical debt will achieve at least 50% faster service delivery times to the business.’”
The numbers are insane.??If engineers spend 33% of their time fixing old problems (AKA technical debt) then the company will lose every competitive race it enters.??More importantly, if you or I saw that number wouldn’t we ask some hard questions about why a third of the team was looking backwards – perhaps even at legacy system repair???And what about estimates that range from 23%-42%???Quite gap, don’t you think???And how?could anyone possibly know?that “leaders who actively manage and reduce technical debt will achieve at least 50% faster service delivery times to the business.”??
What’s the distinction between technical debt – which is notoriously hard to estimate – and new project spending???Is it an easy distinction to make???Why are “old” applications flaws – which in many cases are unknown at the time of initial deployment – carried over to future budgets for long periods of time???If, for example, technical debt is partially “retired” by fixing known software problems, how does anyone know if the fixes don’t create additional debt, perhaps even larger than the debt that?required the fix???Doesn’t this feel like an endless spiral of insanity?
Pay Me Now or Pay Me Later?
Technical debt is alleged inevitable because developers don’t have enough time, money, talent, leadership, requirements – you name it – to do a good job.??But what if they did???Does the phrase “pay me now or pay me later” resonate with anyone???Or is the creation of technical debt just planned shortsightedness???Is the industry’s preoccupation with technical debt self-fulfilling??
There are tools – automated testing, quality engineering, debt estimators, modernization/end-of-life planning, etc. – that correct, improve and manage what everyone seems to think is inevitable no matter how hard a team works to minimize debt.??Early investments generate long-term benefits – if there’s an insistence on even categorizing?imperfection as debt.??Tatum Hunter has it exactly right:??“stop talking about ‘technical debt’ … at best, it’s a way to avoid explaining your work … often, it’s an excuse?for shipping bad code.”
Retirement
The term “technical debt” should be retired.??It’s too hard to understand, avoid, estimate, manage or eliminate especially given the nature of software and the inevitability of imperfect (or evolving) product development.??Something that abstract has no right to exist as a real, imagined or budgetary development constraint.??Let’s just admit that nothing is ever finished and that budgeting should not blame old development teams for debt no one could define, estimate or manage, when all that’s necessary is a constantly evolving slate of projects designed to improve existing and create new applications that will all need to have their oil changed on a regular basis – until they don’t and they’re replaced with a newer model.