Technical debt
isn’t just a term that can be used by overpaid management consultants in a wordy and overpriced analyst report. It’s a valuable concept that engineers can use to explain a complex idea in a sound bite to management.
Modern IT infrastructures commonly ask us to do more with less. There are many ways to achieve this: delay a planned upgrade or overload the memory on your VMware server just a bit more. Maybe another shot at reworking the quality-of-service configuration on the WAN link could delay an upgrade for a few more months? What about hanging onto those end-of-life firewalls for another year? What about skipping the maintenance contract on those load balancers that haven’t had a problem in the last three years? Consider delaying that new hire? Or cancel the training budget?
In the right situation, all of these decisions might make perfect sense. Equally, each of these decisions incurs a debt–a very real, tangible technical debt.
Cancelling the training budget will result in both disappointed staff and skill reduction. Smart solutions are more likely to come from people who have the confidence to make decisions, which can be arrived at utilizing knowledge gained from training courses. Similarly, delaying a new hire increases stress on your team and affects morale in the long term.
Those end-of-life firewalls are likely to have security vulnerabilities, in addition to performance limits. Failing to replace them can result in performance bottlenecks, weird behavior and increased risk of a security breach.
Reworking the quality-of-service configuration is time-intensive and complex, as it’s a tricky technical problem that’s more art than science. Hundreds of hours of valuable BAU time can be poured into attempting to improve bandwidth. Is this the best use of an engineer’s time?
Squeezing another server into the VMware leads to degraded performance and more time wasted. Delaying that project means productivity gains aren’t realized.
All of these decisions lead to a technical debt–a debt that has to be paid back, eventually. It’s not obvious that a delayed software upgrade will improve performance and remove bugs until you need that performance, or the device crashes because of known bugs.
As a network architect, a key part of my role is to recognize these debts and communicate them to management and program directors as a real but intangible cost. And that’s hard. In a world where the bottom lines rules, spelling out the value of doing it right the first time doesn’t sell, but I find that pitching the concept of technical debt forces consideration of operational cost and impact in addition to the simple, up-front capex.
It’s great idea to have when you’re facing the boss. Use it.
Hat tip to Bob Plankers for reminding me of the term last month.
Leave a Reply