A Gold Watch Salute for Technical Debt

by

gold watch technical debtTalented IT teams regularly beat themselves up over technical debt and have built comprehensive plans to effectively manage and minimize its effects. Prodded by Larry Dignan in a recent post, just for today, take a break and instead look at the technical debt practices of enterprise software vendors.

You would think that with their huge teams, the large enterprise vendors would have wrestled technical debt to the ground a long time ago. You would be wrong.

There are several reasons why large software vendors often have technical debt issues as severe or worse than their small vendor/application counterparts. Among these:

  • Some of the companies are public and must continuously roll out new versions and features that goose revenues and profits to keep shareholders happy.
  • Others have been or are about to be acquired, and programmers are laid off to make the numbers look better, which causes the company to lose legacy knowledge as well as the programming skills to address technical debt.
  • Still others are in fierce competitive wars with other vendors and know that shiny new features sell, and assume they can get to addressing technical debt later.

Yet the technical debt buried within these applications can be a ticking time bomb. The more debt in place, the less likely you, as part of an IT team, will receive those amazing benefits the enterprise software vendor promised. Technical debt is one reason why being a late adopter isn’t always the best move: you get the downside of the accumulated technical debt, without the upside of the initial software innovation.

Another concern about technical debt inside enterprise software is the drag on the vendor’s future innovation. As technical debt increases, it reduces software quality and functionality, and forces the enterprise development team to focus resources on fixing the debt, which translates to higher prices.

ticking time bombHow Did We Get Here?

Much enterprise software was designed in a different era, when it ran on mainframes, developers didn’t have to think about mobile apps, people working remotely and running it on today’s much smaller servers.  Software viruses were few and far between.  Competition came from a few, easily identifiable vendors.  And, much of the software was built on traditional code, such as COBOL.  The attitude of software designers was to build in every feature imaginable and let users decide what they want.

Today, much of the code developed in that early era is still recognizable. If you examine the guts of today’s enterprise software, you can often recognize that “kitchen sink” mentality.  If you are considering the purchase or subscription of “new” enterprise software, it would pay to look under the hood of how that code was constructed.

Ways to Identify Technical Debt

To identify serious technical debt issues in the design of the software (finding technical coding debt is much more tricky), here are three questions to ask the vendor:

  1. Is the software built on a contemporary object model?  Ask them for a review of their major object classes and how they are related.  If you don’t have the knowledge, make sure you have someone with you who thoroughly understands object models.  If  all the vendor shows you is the physical design of relational database tables, you may be looking at very old thinking and programming.
  2. Is the software systematically effective-dated?
  3. Are all the business rules that drive the software abstracted to effective-dated metadata?  Can their metadata be configured non-destructively?  Are there any business rules expressed as application code?

To be fair, any enterprise vendor who has been in business for more than a few years will have some technical debt.  You should ask how quickly and effectively their team is working to manage and minimize technical debt.

While it’s somewhat comforting to know that even huge software vendors struggle with technical debt, it’s critical that you get a handle on their technical debt issues as part of your strategy to handle your own.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Tim Johnson President at UPRAISE Marketing and Public Relations
Tim has 30+ years of public relations and marketing experience. Today, his agency, UPRAISE Marketing and Public Relations serves a wide range of clients, earning outsized results.
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|