A dark alley...

A dark alley…

If someone were to approach you on a dark and stormy night as you stood below an underpowered streetlight and ask if you wanted some “technical debt,” I am sure answer would be an emphatic NO. While there are reasons we would intentionally accept technical debt, any development or support team would be better off if they could avoid being shouldered with it.  One strategy to get rid of it is to transfer the ownership of technical debt onto someone else.  Buying packaged software can do this – COTS (commercial off the shelf software) or SAAS (software as a service) can be used as a strategy to avoid owning technical debt.

When an organization buys a supported package or purchases SAAS, they avoid developing specific software development experience (who wants to code an accounting package if you can buy it), shortening the time needed to move from needs-recognition to using the software and avoiding maintaining a staff to maintain the software. In short, the day-to-day management of technical debt becomes someone else’s problem . . . sort of.  One of the laws of software (or at least should be) is that all software includes accrued technical debt. Some portion of the cost initial and annual support or subscription cost of the software pays for the management and maintenance of the software technical debt.

Most software companies do not explicitly publish measures of technical debt in their software, therefore as a user of the software you are more or less blind to level of the technical debt in the package. Why does it matter?  The level of technical debt can still affect your organization even when you don’t “own” the debt. Technical debt in COTS or SAAS impacts the ease of installation, ease of interfacing with your legacy systems, support costs, the existence of latent defects, and maybe most importantly, function agility.  Function agility represents how quickly new features and functions can be rolled into the software.  The longer it takes to develop and integrate new features, the lower the function agility of a software package. The level of technical debt in a package or in SAAS can only be inferred by observing these areas of performance. Review performance in these areas when you are doing your due diligence, and remember that since technical debt tends to build up, performance generally gets worse before it gets better.  And of course, changing software packages is very similar to trying to switch horses while riding (only done by trained stuntmen in the movies, not in real life). So, try to get it right the first time.

A simple cost analysis for determining whether to shoulder the technical debt or to transfer it elsewhere would use the following criteria (assuming the original build/buy decision has been made).

Costs to internally own the technical debt:

  1. Support Staff Costs                            _____
  2. Support Staff Overhead                    _____
  3. Support Staff Tools                            _____
  4. Support Staff Training                      _____

A. Total Costs                                              _____

Costs of someone else owning the technical debt:

  1. Support Cost/Subscription Cost   _____
  2. Support Staff Costs                            _____
  3. Support Staff Overhead                    _____
  4. Support Staff Tools                            _____
  5. Support Staff Training                      _____

B. Total Costs                                                      _____

Net                   Cost        (A – B)                         _____

This is a relatively simple view of the support costs. You should note that there will more than likely be some residual support staff costs needed to interface the new package with legacy systems or just to act as a help desk to initially triage problems. Intangibles, some of which are affected by technical debt such as function agility, will need to be factored into the decision process.

Transferring the servicing and management of technical debt of software by buying packages or using SAAS can make sense.  In many cases COTS and SAAS can reduce amount organizations spend on support and maintenance, including technical debt.  A cost benefit analysis can easily be done to verify whether this is true.  What is less obvious is whether the software’s owner will manage the level of technical debt well. If technical debt is managed poorly, the ability of the package to keep pace with the necessary functionally may suffer. Caveat emptor: do your due diligence and look before you leap.