Probably
the most famous example of technical debt is MS-DOS. Back in 1981, IBM asked
Bill Gates for an operating system for its new PC. To deliver on time, he took
QDOS, (QDOS stood for Quick and Dirty Operating System) and renamed it MS-DOS.
Born quick and dirty, MS-DOS was loaded down with debt from its very
conception, with a poor command set and limited features.
In
the world of project management, on time delivery is a key measure of project
success for most projects. As you rush to meet the deadlines, you may be accumulating
debt silently, invisibly... but incessantly.
Technical Debt may appear as
o
No documentation or user guides
o
Low quality programming
(unstructured, few comments, hard-coding)
o
Badly structured databases (redundant
data, data errors)
o
Poor designs (poor architecture,
not modular)
o
Poor processes (inefficient,
waste time, error prone)
Debt is typically associated with software projects, but it's not only about software - all sorts of project can generate debt.
Technical debt is often generated by the pressure to finish on time, but
it's not just a question of speed. There are several sources of debt.
- Speed: rushing is probably the number one cause of technical debt.
- Short term view: Patching and mending. Non-architected solutions
- Fire-fighting: Focusing on backlog (not on the future)
- "Bleeding-edge" innovation: Learning as you go along
- Lack of skills: Putting staff with wrong skills (or no skills) onto complex tasks
Technical debt is like financial debt... you can ignore it for a while, but the accumulation of debt will come back and haunt you. As you build up debt, you end up with a mess - a patchwork or spaghetti that's difficult to understand or difficult to change.
That's a potential surcharge on everything you try to do - technical debt can slow down and complicate future projects. You may also end up
with premature aging - the accumulation of debt can shorten the lifetime of
your solution.
Don't Sprint into debt.
The main cause of debt is speed. Some project management methods focus
on speed, notably most lightweight variants of Agile. Lightweight Agile methods
such as Scrum can force you into debt if you over-focus on sprints and speed.
You may deliver on time, but if you sacrifice other factors of best practice,
such as design, planning or quality, then you could be accumulating debt.
There are two ways around this problem for Agile projects. You can try
to make your lightweight method more robust (as described in the book
"Managing Software Debt" by Chris Sterling) or you can use an
enterprise Agile solution
How Enterprise Agile helps
Enterprise Agile methods such as DSDM Atern (sometimes branded as AgilePM) allow you to combine agility with architecture and design. Atern also has a project management toolkit to ensure a long-term approach (plans, business case, etc.) - these help to clarify the trade-off between speed and debt (and therefore to remove or reduce debt).
Whichever way you choose, and whether you use Agile or not, you need to be aware of debt. You probably won't be able to be debt free, but you should apply three golden rules:
- Start today to pay back old debts (each new project cleans up some previous mistakes and clutter)
- Avoid new debt (do it right in future, balance speed with quality)
- If a project does have to sprint into debt, clean up the mess ASAP
