While at Interop Las Vegas, I sat on the Ask the Experts panel in the Virtualization and Data Center Architecture track. The audience had questions revolving around various technologies and methodologies, with one standing out from a gentleman worried about moving forward with an application that could only run on 32-bit architectures. As you’re probably aware, those are dying off rapidly – the latest wave of Windows operating systems don’t even have a 32-bit option available. Constraints such as this are daunting, especially as so much noise is made around other ways to deliver applications with virtual machines and containers.
The reality, however, is that problems like this are more common than it seems. Businesses love to delay fixing architecture, technology, and hardware issues until they become so painful that there’s no other choice. This is called Technical Debt. Put simply, this is the concept of paying a tax on poor decisions made in the past that are focused on technology. The tax comes in many forms – poorly written code, hardware refresh delays, and other band-aids applied to make things last just a little bit longer – but is most often represented as operational efforts required to set things straight. The corrective effort will exceed the amount of time it would have taken to do things right the first time.
The folks at CommitStrip have a fairly concise flowchart demonstrating this in the software world. 🙂
I can do a quick fix right now, but someone will have to redo it and fix it properly at some point. It’ll be difficult to debug and in the end it’ll take twice as long. (source)
Technical debt isn’t a technology problem; it’s a people and process problem. And often not your problem, originally, but something you’ve inherited. You’re paying off someone else’s technical debt. Perhaps it was a decision your boss made, or a co-worker that has since left the company. In some cases, someone at your last job is paying off your old technical debt. Right now. Ouch, right?
Confusing Debt with Blame
Technical debt is often translated into a technology blame. Take the 32-bit application constraint as an example. You might want to blame Microsoft for not continuing to provide a 32-bit operating system. It’s their fault! And as such, lash out at the vendor and label this a technology problem. However, I see this as highlighting a long tail of technical debt that is being called to term. It’s time to pay up, and pay up you will.
How does one start to pay off this debt? First, it’s a good idea to have major pitfalls documented for future knowledge. 32-bit operating systems have been fading away for years. It’s not a surprise. Thus, it’s good to recognize this and start documenting the debt. Perhaps submit it to your PMO (Project Management Operations / Offices) or CAB (Change Approval Board)? Assign it a risk value with your architecture team or, if you are the architect, with your internal road map?
These little blips also make great examples of how to steer the forward-looking architecture decisions held by the Project Management / Product Management teams. Point out how poor decisions have cost the company time, money, and other intangible resources. Assign weighted risks to corner-cutting decisions and raise a red flag. If a project kicks off without any thoughts to strategy, architecture, or road map, raise a red flag. After all, 90%+ of the time spent on any successful project is the design work. Implementation is trivial in almost all cases. Awesome implementations can’t fix a poor design.
Or if all else fails, just subscribe your technical team to CommitStrip and enjoy the laughs. 🙂
