Recognize the High Cost of Low Technical Debt

Sometimes managers struggle with determining if an innovation from a new technology will be worth the improved performance or features. Upgrades are expensive, and the decision to upgrade can meet unwarranted management resistance if a clear reason is not present.

But for analytics, whether applied to a marketing chatbot or developed as a precursor for advanced predictive models, delays in upgrading supporting software, data sources, or associated training can create technical debt. Managing the small tasks can leave your organization at a disadvantage in the race to establish a data-driven strategy.

Technical debt is a software development term in which an implemented software fix solves an immediate problem, but consequently creates potential complications down the line, raising the total cost of the software. The fix usually occurs to support a tight deadline and limited budget. Its implementation may seem like a “savings,” but the consequential complications create a “cost” that the organization must face -- a needed repair or renewed training. Think of technical debt as the development teams’ version of an accounting shell game, and you have the general idea.

For years technical debt applied solely to the decision making relating to selecting an architecture for developing websites, apps, chatbots, and other software. Products and services began to include that architecture for programmable features, with associated data become equally widespread. Over time IT professionals began to encounter more technical debt considerations when managing analytics and data-driven operations.  

Technical debt seems like a low-level managerial concern. But it can accumulate when no overview of systematic code maintenance occurs. A given code can contain dependencies and frameworks to function correctly, but these features may be optimized for a specific local need rather than the overall system where a program operates. The myopic focus on a function with no reflection on downstream systematic consequences can begin to create project management challenges, reducing time available for other strategic analysis or meaningful development.

To get to the heart of avoiding technical debt, managers must bake complexity into their timelines to replace technology. Because technology naturally introduces complexity in operational logic, the first question that should be asked is about what is being maintained with the stack? Doing a mind map can reveal what potential relationships exist downstream from a decision.

All technical stacks have a burn rate, a lifecycle of utility. The usefulness of a stack has a threshold. Mapping out a scenario for what impediments to utility looks like can help determine how much time is available until updates become necessary.

An IT manager can inherit technical debt from how people are managed in a project. A manager can run into developer egos that are limiting what information will be shared. The best means to defend against it is to focus all teammates on maintaining good documentation. That documentation allows a team to establish a shared understanding of root causes of problems, and avoid "doc rot", the deterioration of information quality because a document was not updated in lockstep with software changes.

One thought I share with clients is that delays in examining your data creates missed opportunities to market your business or serve customers better. Reducing technical debt appears to be a menial task, but its potential is enormous when it comes to minimizing delays and bringing best-in-class value.

For more on software development in the enterprise check out these articles:

DevOps Gives Nationwide Building Society an Edge on Upstarts

The Key Attributes to Look for in a DevOps Trainer

The End of Agile? Not a Chance.

IT Careers: 10 Job Skills in High Demand This Year