Software Development

More than Software Debt….Technical Bankruptcy

Software Debt goes back to the very beginning of development but the metaphor was first voiced by Ward Cunningham when he compared technical complexity and debt in a 1992 experience report:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

Now what happens when the debt load gets so great that the organization is brought to a stand-still, as referenced by Ward Cunningham?

I believe we need to extend the use of the same metaphor from the financial sector and analyse technical debt first from a numbers point of view before diving into the technical problem solving. In finance an organisation is regularly audited to ensure that its records are accurate, part of an auditor”s job is to determine and comment on whether the organisation is a ”going concern” generally if an organisation goes into bankruptcy in between audits and a comment on whether the organisation is a going concern has been incorrectly stated, the auditor is first to be sued by those using the auditor’s report (investors, etc.).

The statement is based on whether the business can continue without going into liquidation for a period, usually 12 months.

Do you have a ”Technical going concern”?

In the case of technical debt I believe management should also look to see if they have a technical going concern and if there is risk of technical bankruptcy

To ascertain the health of a software product the first step is to audit/review the product development group in terms of the following, for each category producing the effort needed (equivalent to the financial budget for each):

  1. Open defects that are real to customers. This should be in terms of total number, and estimated time to fix. The key is turning this into a value that can be used in the final analysis.
    • First the defects need to be ordered in terms of criticality (the priority in which they need to be fixed for the customer) and count all that are hindering the customer in the use of the product (anything that is none cosmetic).  
    • Then estimate time & resources needed to solve the issues and get it to the customer. This could either be estimated person-hours for defects. You should end up with a figure that represents the effort needed against time.
  2. Engineering Practice issues that are impacting your release cycle, getting the product to customers. Identify issues that repeatedly cause lost time, order them by the resulting value of ”occurrence per release cycle” multiplied by the ”total person-hours wasted for each occurrence”.   
    • Choose a cutoff point such as anything of 6 person-hours (a good value for 1 person-day), also eliminate any that can be fixed in less time/cost than they absorb, as these should be a no brainer ie fix in the same time wasted.
    • Again use this final list to give you a figure that represents the effort needed against time. For a SaaS/Web operation the issues would be like those here (similar issues apply to box product release also):
      • Build failures
      • Regression failures
      • Server configuration issues
      • Data structure issues
      • Post release issues that were not caught in testing
      • Any pattern based failure that repeats

These two values should be represented in terms of the resources needed over 1 year and in terms of each quarter, this is generally how all businesses operate and product development should fit into that cycle.

For example:

Then as shown the investment needed to implement features, this provides the ability to balance the books against the capacity of the teams available. Now there are all the details of skill sets, not subdividing teams, etc. however this is an exercise in determining high level feasibility; in practice I have produced much more complex models to valid the effort needed.

However, in my experience if you are already in the red or just barely in the black at this level there are significant issues and you are looking at the organisation not being a technical going concern.

In the last year I have come to like Chris Sterling’s definitions of  ”software debt” and would broaden the calculation of effort to these categories, I have added my view of the way to quantify this from an audit perspective:

  1. Technical Debt: those things that you choose not to do now and will impede future development if left undone
    • Captured as the effort needed to stop compounding the debt, also the effort needed to deal with customer defects as stated above.
  2. Quality Debt: diminishing ability to verify functional and technical quality of entire system
    • Capture as the effort needed to develop and implement a sustainable test harness.
  3. Configuration Management Debt: integration and release management become more risky, complex, and error-prone
    • Capture as the effort wasted on each release cycle through configuration errors. Also the effort it would take to fix these issues.
  4. Design Debt: cost of adding average sized features is increasing to more than writing from scratch
    • Capture as the effort needed to redesign parts of the system where new or enhanced functionality is not being delivered. ie. When it cannot be classified in the new feature bucket. This can be difficult as you would be looking to always deliver customer benefit, but we all know it when we see it you just have to be honest with the attribution of effort.
  5. Platform Experience Debt: availability and cost of people to work on system features are becoming limited
    • Captured as the cost of replacing those key holders of knowledge when you have the risk of becoming single threaded. This one is event driven so should be categorised as risk and used in ”what-if” scenarios.

Are you in technical bankruptcy or heading there?

Step two is to determine if you product is heading to technical bankruptcy and if you can do anything about it. For me, the gauge of this is can you effectively tackle the Technical debt in a 6 month period so that it absorbs less than 50% of your overall resources and then be able to sustain a trajectory to reach 20-30% of your overal resources within 1 year. If you cannot do this you are heading to technical bankruptcy or are already in it in my view.

If you are, or can get to being, a technical going concern then maintaining a simple audit approach through what should be standard metrics of a development organisation is a useful management practices to watch as any CEO or CFO would watch his balance sheet.

If you are technically bankrupt what are the options?

For me you have two options:

  1. Technical Restructuring – force the 70/30 split with 70% of your resource going to build a new structure. Again you need to be doing this within 12 months. Getting close to 12 months or going over is rarely successful. During the restructuring enlist the rest of the organisation to manage the inevitable heat from your customers, this kind of undertaking is not a technical endeavour it is a business endeavour and needs the support of everyone involved in the business. Part of the restructuring may require gaining additional outside capital for the investment, these kinds of efforts are not normally cheap.
  2. Limp along until customers flee your product for competitors, during which time the management of technical debt will become the entire focus of the organisation with ever-decreasing market differentiation.

Basically once you are approaching, or in technical bankruptcy,  just as with financial bankruptcy you only have expensive and high risk options available to you, so it’s better not going there… attention to technical debt and audit against it regularly.