Debt

What about the kids?

We hear about and discuss debt on a regular basis. The USA national debt is skyrocketing. Personal debt levels are at all time highs. Most of us know what too much debt means on a personal level. I borrowed too much money last year. Now I am spending disposable income (fun money and savings) to maintain that debt – paying interest.

Debt can be useful, a vehicle.

I went into debt to pay for college. It was worth it, and I am not just talking about the keggers. I didn’t feel that way the first year out of college, but eventually I earned much more money because of the education.

I bought a house… in California. It was really expensive. I would not have been able to buy it without debt. Without that debt, I wouldn’t be upside down with negative equity. Alright, bad example of a good use of debt. That doesn’t mean there aren’t good examples.

There are many kinds of debt. Mortgage loans, automobile loans, credit cards, pawn shop loans, payday loans, and loan shark loans. I can owe somebody for a bet I lose. I owe my wife for being patient with me. I knew a guy in high school that never gave back my Kiss Alive album – he owes me.

Technical Debt

Ward Cunningham coined the term technical debt as a metaphor to choosing to owe the work of refactoring software. His idea was that an organization could release software even if they didn’t fully understand the problem that software solves. Others have decided that we can write bad software code expecting to clean it up in follow-on releases.

Martin Fowler said in his bliki that it “may be sensible to do the quick and dirty approach.” How? If a company lives to fight another day, if it gets the release out before a competitor to gain a foothold on a market, if technology can improve enough to cover our problem.

I read about technical debt in software quality magazines in the early 2000’s. Most of the technical debt that I have heard about relates to bad software design or spaghetti code. Recently in a NetObjectives-taught class, I heard about two different kinds of technical debt – manual test debt and defect debt. Manual Test debt is a build up of manual tests that have to be run on every release. The cost is in longer harding/stabilization iterations and regression defects found later in project schedules. The Defect debt is a build up of defects that were not caught before the releases of software. The cost or interest payment is in spending time on escalations – untimely interruptions – instead of working on new releases.

So I started thinking about what other kinds of technical debt there is.  I am a software quality engineer so I could associate with the cost of the Manual Test debt. I have also seen teams running manual tests that had been replaced by automated tests when the automation failed (alright, it was me) – Broken Auto Test debt. That’s like sending in the check for your car payment then walking to work because it needs repairs. It happens with X-Unit tests too.  I have also found there were features on old products that didn’t have tests, or they were not properly maintained. How much does it cost in test execution velocity to rewrite test objectives? Because test development takes more time than execution, you could face the cost of release delays from Test Maintenance debt.

If a product is brittle, a good tester only needs to run informal tests to find a lot of defects. Unfound Defect debt is expensive. But what if they are found and deferred? Unfixed Defect debt is a problem to customers that cost escalation time, and it might make them madder if they think you chose not to fix the problem. If a project releases with unverified defects because of a “hard date”, the cost will be the defects that cannot pass verification. It’s a cross between unfound and unfixed. What would you call that?

A product can be popular if it supports more configurations than competitors – operating systems, databases, application servers, java virtual machines, and the versions of each – they can be money in the bank. But support costs for each are expensive, testing more combinations too. The cost of monitoring which are supported, selecting which your next product version will support, and keeping up with training to use the new versions will reduce the value of those sales. I will call that Configuration Matrix debt.

Bundles also help in making sales. Getting two products work together through various technologies like web services and odbc connections are easier than ever. Integration debt is the cost of supporting all of the upgrades of the integrated product with your old version, or vice versa.

I hope that I can get some comments on other types.

Recognition

The first time I talked to that NetObjectives trainer about technical debt in the project team I was on, I thought that Suze Orman was yelling at me. Alright, so I am in debt. Now what? “Don’t get further into debt” was his answer. I decided to watch for all kinds of technical debt. Situations that caused later pain because of decisions that were made for immediate gratification. Every decision that you and your team makes should ask the question – am I paying later to pay less today? The choice you make should be based on how much you are paying for yesterday’s decisions.

– Dave McNulla