Apollo 11 Mission on Technical Debt
Back in 2009, the source code for the Apollo 11 spacecraft was transcribed from scanned images and put online for anyone to view.
The code is a true testament to programmers ability to do a whole lot with very little. More importantly, it shows that whether your end goal is to generate sales reports or fly to the moon; the programming required will largely be the same.
Here is a short snippet of code from the project (with developer comments included):
CAF TWO # WCHPHASE = 2 — -> VERTICAL: P65,P66,P67 TS WCHPHOLD TS WCHPHASE TC BANKCALL # TEMPORARY, I HOPE HOPE HOPE CADR STOPRATE # TEMPORARY, I HOPE HOPE HOPE TC DOWNFLAG # PERMIT X-AXIS OVERRIDE ADRES XOVINFLG
At some point 45 years ago, a programmer wrote and submitted this code while consciously accepting some amount of “technical debt”. Technical debt is a metaphor used to describe the eventual consequences of poor software design decisions within a codebase — or more simply — the extra development effort that is required when code that is easy to implement in the short term is used instead of applying the best overall solution.
In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design.
Talk with any developer for a reasonable amount of time and you may hear phrases such as “bandaid fix” or “hack”. These are often good indicators that a sacrifice has been made (generally for time) and that technical debt was accrued. Additionally, you should not be surprised to find almost any codebase littered with TODO and FIXME comments — left there by developers in the hopes of someday returning to refactor.
In software development, proper care must be maintained in order to prevent accumulated technical debt from becoming a burden on a project. To keep the work flowing smoothly, teams must show special attention to paying down and preventing technical debt.
Budget for technical debt in release planning
Track technical debt in a product backlog
Ensure the Definition of Done is kept up-to-date
As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.
— Meir Manny Lehman (1980)