In a previous podcast, Network Broadcast Storm Episode 5 – Network Monitoring, I talked very briefly about technical debt but after listening to the show I thought I really didn’t do the topic any favors so I thought I’d write about it here briefly. I see technical debt as anything you do in taking a shortcut that could jeopardize the operation of your solution or its underlying design. The term technical debt is often referred to in software coding but it applies equally to networking and systems administration. I’ve occasionally heard the term “skeletons in the closet” used to describe the same. Often we have both timeline and budget constraints that push technical debt upon us, shortcuts here and there that eventually catch up with all of us and ultimately can bring the house of cards crumbling down around us. In my day to day I’m usually fighting either the clock or the budget, struggling to find the time and resources to-do the proper research and then test the configurations or trying to figure out how to get by with some budget $$$ amount that someone else came up with and really leaves some significant shortfalls in the design. Technical debt can be as simple as failing to-do the redundancy and failover testing or it can be more material such as having a single power supply in your only domain controller or having both power supplies in your only domain controller connecting to a single PDU. I often have discussions, I would occasionally call them negotiations, with my management team trying to convince them where we can be frugal and where we just can’t afford to cut corners.
It’s our jobs as the technical experts in our various fields to help educate and advise our employers or clients when determining timelines and project budgets. The goal is to strike a balance, if our employer or client is only worried about 99% uptime then we can reduce the design appropriately. If they are willing to accept 802.11n instead of 802.11ac, or 100Mbps to the desktop instead of 1Gbps to the desktop, or 1Gbps uplinks instead of 10Gbps uplinks those are all compromises that directly impact the design requirements and ultimately the costs. In my opinion the key is striking a good balance between cost, time, features and requirements.
I’m usually pretty passionate about technical debt because if the solution doesn’t work who do you think the users will be coming back to? Who is the help desk going to be calling at 2AM on a long holiday weekend?
What do you think? Any stories to share?
Image Credit: Pierre Amerlynck