“Technical Debt” – What is it?
Like credit card debt, technical debt describes the causes and the associated ‘costs’ (both in time and money) of missing and/or outdated IT infrastructure documentation and un-commented configuration or code changes. Both are often forgone using justifications like, “it’s temporary!” or “there’s no time, we have to be the first to market!”
There are times when this trade off can be worthwhile: the key hours and days saved can, in some cases, make the difference between being first to release to market and capitalizing on an opportunity — or missing it completely by losing out to a competitor.
Though intentionally taking on technical debt can be risky, when an important customer is breathing down your neck with an issue, it can make sense to jump right into troubleshooting their issue. In these high-visibility, high-stress moments, taking on a small amount of technical debt to re-create the customer’s environment and engineer a fix may well be the right thing to do. In situations like this, getting an important customer the help they need quickly can be a valid reason to forego documentation and commenting… in the short-term.
In some of these cases, incurring a bit of technical debt can be a good (short-term!) business decision. Down the line, however, should that technical debt not be rectified, the costs of debt will begin to come to light. When the next customer contacts support with the same issue your engineer previously fixed, that skipped documentation means all the time previously “saved” (by forgoing documentation) goes to waste while the new tech repeats the same diagnostics work. Had the fix been documented the first time around, a search of the ITSM / trouble ticket system would have quickly revealed the solution. Hopefully this time around, the fix is documented!
This simple, common example of technical debt can result in a company wasting days, repeatedly troubleshooting an issue that had already been solved. Were it not for this accrued “technical debt”, the issue would have been resolved in mere minutes the second time around! Weather in a bid to be first to market, or while working to produce a working MVP (minimum viable product), there’s always a price to pay for accumulating technical debt — both in the short term, and over time.
Technical debt accrues interest
Like all forms of debt, technical debt, too, acquires interest – which must eventually be repaid. As time goes on without repayment, changes to a growing IT infrastructure (or code base) become exponentially harder (think compound interest). As a result, productivity can suffer, and eventually, even employee morale can be affected by the extra work outstanding technical debt can result in. An IT Engineer may find him or herself extremely frustrated in the midst of resolving an issue, for example, profusely cursing the Engineer who did the original work for failing to comment or document the changes that were made — Only to later realize they were that Engineer.
As work is repeated as a result of previously accrued technical debt, this time is lost forever. Should this initial technical debt not be rectified, the extra time it takes employees to do their jobs because of it results in a strong temptation to take more shortcuts to make up for that lost time. Often, when shortcuts are taken by engineers, the first thing to go is documentation of the work being done. This, of course, results in yet more technical debt.
If this situation is not consciously halted and rectified, new technical debt will accrue on top of existing technical debt — in an endless, circular cycle. Eventually, IT engineers can spend so much time working around previous “temporary” fixes and “time-saving” measures that the new work queue grinds to a halt.
The “tipping point”
The technical debt ‘tipping point’ is often reached suddenly, and by the time it’s realized, the debt has often piled too high. Technical debt has put companies out of business in the past, and the problems it causes never go away on their own. After reaching the infrastructure technical debt ‘tipping point’, sudden problems and avoidable emergencies that tend to yank engineers away from valuable project-type work occur with more and more regularity.
Once neat racks now sport only “spaghetti” wiring (unlabeled, of course), while only passwords that are no longer in use are stored in your centralized password database (you do have one, right?). SSL certificates catch engineers by surprise as they expire without warning, under-licensed software refuses to install… Your engineers become ‘fire fighters’, of sorts, and their stress goes through the roof.
No matter how prepared you think you are — it only takes one engineers mis-step to bring down your entire IT infrastructure. The chance of an engineer causing an unexpected outage increases exponentially as technical debt, and the temporary “band-aid fixes” it results in build. To avoid this situation, organizations need to both understand the costs of infrastructure technical debt, and insist their engineers do not skip documentation and contribute to it.
The “hit-by-a-bus factor” is one way to examine how much technical debt your organization has already incurred.
Avoid infrastructure technical debt – Device42 can help!
The best move is to Avoid this entire situation. End your enterprise’s reliance on manual IT documentation, and let Device42 do the hard work of creating and maintaining a near-real time map of your IT infrastructure, discovering changes made to your IT infrastructure shortly after you make them. Furthermore, Device42 helps you manage the entire life-cycles of your IT assets, including both hardware and software, plus their warranties. It will even help ensure you stay on top of your SSL Certificates!
We hope you enjoyed this article. If you’re struggling with technical debt and you see the writing on the wall – Download Device42 today to get your IT infrastructure under control!
Questions about this post? Need help with something? Let us know in the comments, or email [email protected] with the subject “Device42 tip”! We’ll follow up with a post featuring your user-submitted tips and tricks.
Device42 users already have first-hand experience with the benefits automating the discovery and documentation of IT assets bring to the table. Gone are the days of putting the same information in multiple places; No more struggling with Excel spreadsheets to track networks or Visio diagrams to identify critical application dependencies for next week’s big maintenance or that upcoming migration.
Experience it for yourself!
Download a trial of Device42; it couldn’t be easier — Click here to get started!