Technical debt, a developer’s term for trade-offs, is starting to impact marketing tech and other choices. Here’s how IT teams can reduce the impact of technical debt choices.

Pierre DeBois, Founder, Zimana

March 6, 2020

3 Min Read
Image: Shutterstock

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

About the Author(s)

Pierre DeBois

Founder, Zimana

Pierre DeBois is the founder of Zimana, a small business analytics consultancy that reviews data from Web analytics and social media dashboard solutions, then provides recommendations and Web development action that improves marketing strategy and business profitability. He has conducted analysis for various small businesses and has also provided his business and engineering acumen at various corporations such as Ford Motor Co. He writes analytics articles for AllBusiness.com and Pitney Bowes Smart Essentials and contributes business book reviews for Small Business Trends. Pierre looks forward to providing All Analytics readers tips and insights tailored to small businesses as well as new insights from Web analytics practitioners around the world.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights