What is technical debt?
The father of the Wiki, Ward Cunningham, coined the term “technical debt.” He used the word to refer to the built-in inefficiencies of software, which could be caused by developers rushing software into production or it could have happened by them building software with vague requirements. Another common cause of technical debt is over-excessive customization of off the shelf software – forcing the software to do what it was never designed to do.
With all respect to Cunningham, I’m going to broaden the idea of technical debt. What if it also encompassed inefficiencies in the work itself, like time wasted on work-arounds or money spent to compensate for bad data. Cunningham also uses the term “burden.” Just like in our personal lives, whenever you have debt, you must pay interest. So rather than use the word burden, maybe we think about the residual effect of technical debt as technical interest. It’s the price or penalty in wasted effort or inefficiency associated with technical debt. It is not limited to money either, it could be low customer satisfaction, poor employee morale, or networks that aren’t resilient.
What does technical debt look like?
This is a rather abstract idea, so allow me to share an anecdotal story. For over 10 years, I’ve worked with telecommunications companies of all sizes. A fairly consistent scenario I’ve observed in my work has to do with walk out surveys and field verification of designs. A network planner or designer will create a new network design that might include underground installations through duct banks and handholes.
Before moving forward with the design, the company would send an employee out to the field to investigate each handhole or duct bank to ensure there were, in fact, empty ducts and ports available for use. Why would they do that? Because they didn’t trust their own records. They had CAD files, a provisioning system, maybe even a GIS yet they were not integrated, and accuracy was suspect. It was less risky to drive into the field, open every cabinet or handhole, take a paper map of the design and verify the conduit and ports were available. Rather than change the process and fix the fundamental problem of inaccurate data, they continued with the truck rolls and field work. They would not eliminate the technical debt.
Another way to identify and quantify technical debt has to do with data latency. We are all familiar with the concept of network latency, but now think of it in terms of your telecom’s business itself. How much time lapses between a new network edge-out or extension or upgrade and when your GIS reflects that updated information? To put it another way, how long do new capital investments sit idle before sales knows they can sell services on it? I’ve observed timelines ranging from 48 hours to up to six months. If it takes weeks to incorporate network changes and additions to your corporate GIS, it’s like paying only the minimum payment on a credit card.
To Eliminate Technical Debt, Change the Process
One of the most common questions customers ask us lately has to do with NextGen Network Management in ArcGIS – “What is the return on investment of implementing the utility network?” Telecoms are also asking:
- Will the implementation positively impact my key performance indicators?
- Will it reduce overtime, operations, and capital spending?
- Will we see reduced outages and network downtime?
- Will employees do their job faster?
- Will our company have fewer safety incidents?
The answer is yes. How? By reducing imbedded inefficiencies, i.e. lowering your technical debt.
Does it take effort? Of course it will! Paying off debt is rarely a fun or glamorous event. But it’s a fantastic feeling once the debt is eliminated. Telecoms will have to add data missing from their existing network records. They’ll need to overhaul entrenched workflows. It might involve completely re- imagining the way telecoms think about GIS.
ArcGIS Pays Down the Technical Debt
ArcGIS may not be able to pay off your mortgage or student loans. But it can sure save you money and reduce your interest payment on your technical debt. How?
- Extensive attribute rules – ensures data is accurate and consistent as its created
- Precise modeling of devices – realistic modeling in both 2D and 3D, resulting in a digital twin
- Enhanced security – adheres to the highest standards
- Services architecture – enables network functionality to exist on any device (yes, even mobile)
- Network technology agnostic – model fiber, coax, wireless, copper networks in one place
The digital twin can be a reality if we peel away our pre-conceived notions and cognitive biases of how things are done. NextGen Network Management in ArcGIS takes advantage of modern technology to completely reimagine process of designing, building, modeling, analyzing, and sharing one of the most precious assets a telecom has: its network infrastructure. ArcGIS offers an opportunity to do the things the dreamers in your organization have envisioned for years. It presents an opportunity to see work-arounds and assumed constraints for what they really – interest payments on technical debt. ArcGIS drives innovation and transformation because it helps telecoms see the possibilities when bad habits are replaced with healthy habits.
