Your full service technology partner! 
-Collapse +Expand
Search Industry Group:

-Collapse +Expand Industry Store

Prestwood eMagazine

August Edition
Subscribe now! It's Free!
Enter your email:

   ► KBIT Water-Coo...   Print This     
  From the January 2008 Issue of Prestwood eMag
Industry IT Water-Cooler for Power-Users:
Technology Debt: Is it getting to your bottom line?
Posted 13 years ago on 12/20/2007 and updated 6/12/2008
Take Away: Technology Debt is a rather loose bucket in which we can lump many things that come back to bite your projects. Put simply, it's like the old Fram oil filter slogan: "Pay me now - or pay me later." Unless a project has a very short life expectancy, the things that are put off today will almost certainly have to be revisited and dealt with later - sometimes with "interest." Here, we talk about what comprises technology debt, and how to keep it from degrading the profitability of our efforts.


Are you actively evolving your business database application? If not, does that mean your company is not evolving? If your company is evolving and reacting to a changing business world, your business database application needs to change too. The managers running the business frequently have changing needs.

In the world of agile and lean software development (of which our PSDP software development process is an advanced form), there's a long-standing axiom: "You never get it right the first time." This is not always true, but the more complex a project, the truer it becomes.

Working hard, often with a looming deadline, developers don't always see the cleanest, most elegant way to implement a solution. This doesn't mean the solution won't work. It may, in fact, work very well. Frequently, though, it could have been better - usually in more ways than one.

With modern development tools, software code is more than a set of instructions to a computer. It's also a repository of knowledge about your systems and your business rules. When the software is designed and written in a manner that makes it easy to discover and understand your business rules, it imposes little technology debt - at least not in that department.

To illustrate the other end of the scale, I'll use an example that is both exaggerated - and over-simplified:

Suppose we're talking about a HR management system, and one of its functions is to compute paid time off (PTO) for each employee. Naturally, you have one or more policies that dictate how PTO is earned, etc. And, in the first iteration of the project, somebody has failed to give your developers one or more of the small - but important - details.

Thinking the task is fairly simple; the developer might write a function to calculate PTO. Several factors are known to affect the calculation, so he declares variables for them:

'wdw' is a numeric variable that will hold the number of week days worked.

'oth' is a numeric that will hold the number of overtime hours worked.

'wnd' is a numeric that will hold the number of weekend days worked.

Using wdw, oth, and wnd, the developer writes the function. As is typical, each of those variables will need to be manipulated, according to the known business rules, several times within the function's code.

Here's where technology debt kicks in. Six months down the road, the original developer is gone, but the team is given the rest of the business rules. A developer is assigned and, studying the existing code, 'wdw,' 'oth,' and' wnd' are near inscrutable. He has a choice to make:

Does he live with the existing code, and add to it in similar style? Or does he first "refactor" the code to make it more understandable?

Refactoring is just a fancy word for reworking existing code to make it more easily consumed by the developer (though it has other purposes, too).

In our example, our new developer will probably rename 'wdw' to something like 'weekdaysWorked; 'oth' to, say, 'overtimeHourWorked;' and 'wnd' to 'weekendDaysWorked.'

Naturally he can't merely rename the variable declarations; he has to rename each instance in which they are used in code.

Fortunately, modern development systems include refactoring tools that cut this task down to size.

Now the developer has understandable code to start with, and the job of updating it to reflect the recently disclosed requirements is much easier.

The first developer (and the incomplete requirements) created the original technology debt. The second developer paid the debt, and, if he does a good job with the enhancements, doesn't introduce new debt.

For customers, there is a potential secondary problem with technology debt. Renaming variables doesn't change the way the code works one bit. It doesn't deliver any tangible value. It can even be classified as waste.

It's useful, then, to think of more than one kind of waste: necessary waste - and unnecessary waste. Although refactoring delivers zero tangible benefit to the customer, it falls into the necessary waste category because it reduces technology debt.

Technology debt can't be seen, but it must be paid - someday.

The sooner it's paid, the less "interest" mounts up.

Technology debt looms in other places too:

  • Is your project married to a particular database? If so, there's going to be a technology debt payment due when that database becomes obsolete.
  • Is your project built with a "consumer grade" desktop database (FileMaker, Paradox, Access)? The technology debt can be enormous when the development system vendor allows their product to languish - or when new requirements are overly cumbersome - or impossible to implement.
  • Did somebody press a spreadsheet into service when a database would have been more appropriate? That's a biggie.
  • Does your project have dependencies on third-party code libraries? Are you keeping them updated? Are updates even available?
  • Was your project coded using good object-oriented methodology, and proven design patterns? If not, the interest is mounting daily.

It is impossible, of course, to altogether eliminate technology debt. Applications that were perfectly engineered for Windows 2000 and XP suddenly look "old school" when run on Windows Vista. They might not run at all if they break some Vista rules that XP developers had little chance of anticipating.

But technology debt can be minimized, and it can be managed.

One thing that can help: Perform an annual "technology debt audit" on your projects. You may decide to defer payment; you may decide to pay it off now, and put the brakes on the interest; or, you may choose to make scheduled, incremental payments.

The cost of servicing your technology debt should be included in each annual budget.

Like death and taxes, when it comes to non-trivial software systems, there are two things of which you can be certain:

  • If you have legacy projects that haven't been recently reviewed you have technology debt.
  • As long as you have technology debt, there will be a day of reckoning.


Share a thought or comment...
Write a Comment...
Sign in...

If you are a member, Sign In. Or, you can Create a Free account now.

Anonymous Post (text-only, no HTML):

Enter your name and security key.

Your Name:
Security key = P1102A1
Enter key:
Article Contributed By Wes Peterson:

Wes Peterson is a Senior Programmer Analyst with Prestwood IT Solutions where he develops custom Windows software and custom websites using .Net and Delphi. When Wes is not coding for clients, he participates in this online community. Prior to his 10-year love-affair with Delphi, he worked with several other tools and databases. Currently he specializes in VS.Net using C# and VB.Net. To Wes, the .NET revolution is as exciting as the birth of Delphi.

Visit Profile

 KB Article #100747 Counter
Since 4/2/2008
Go ahead!   Use Us! Call: 916-726-5675  Or visit our new sales site:

©1995-2020 Prestwood IT Solutions.   [Security & Privacy]