In one of my previous blog articles I talked about Software Debt escalating to Technical Bankruptcy, here I will explore more the need for and apparent lack of monitoring of accrued software debt within businesses. The lack of understanding of software debt by business managers, particularly those based on software as their primary product, is a fatal mistake in their business strategy in my view. It is akin to only looking at the sales numbers and not a the operating expense, one day you’ll find yourself paying more for a sale than the revenue from the sale.Recently I used the idiom ‘the straw that broke the camel’s back’  to convey this point, I particularly liked it as the original Arabic proverb describes how a camel is loaded beyond its capacity to move, that is exactly what happens with software debt the organization gets to the point that it cannot move forward. The basis of the analogy I used to convey the impact to software production was that the straw on the camels back was composed of :

1. Software Architecture that was pushed beyond its original intent.
   • New architectural approaches partially implemented, tactical features always took precedence.
   • Multiple partially implemented architectures, etc.
2. Poor development practices
   • giving up Unit Tests for speed of delivery
   • inconsistent application of code and design reviews, etc.
3. Poor product management decisions
   • only looking for the customer facing UI components and ignoring the back-end implications. Great blog on this behavior here.
   • never prioritizing technical debt over features, etc.
4. Poor Operational and Deployment practices
   • No Continuous Integration, No common build system, etc.
   • No standard configurations, manual deployment at all levels of the system.

You probably get the picture, I left out a lot of the specifics above,  and for the business management I kept it to the four headlines above. It got the point across to them and we immediately started to look at ways to deal with the issues. The temptation to revert to prior behavior was always present and the question of ‘are we there yet’ kept on coming up and this is the fundamental problem, believing that Software debt will disappear is a complete fallacy, it is always present and takes constant management to stop it from getting out of control. So it is imperative in my view to manage it from the beginning and if that time has already passed then from this point forward, pretending it is not there is like not opening the credit card statement each month. There are indications that this is becoming more central to business discussions, great post here, however it seems that Agile approaches are placed central to it, I have to say Agile is making it visible and by no means is Software Debt limited to these organizations. So how should we manage Software Debt and make sure it is visible to the Business Management. First is to communicate and educate business management on software debt, it is not taught in MBAs or in business school so few a likely to even understand the phrase let alone the details. Secondly keep it simple, I see all of the types of issues in software debt as defects, yes they need to be categorized into useful groups so that a plan of action can be created to tackle them, but they are all defects of one sort or another. The defect may appear due to changes in desired use, they may just be there because we took a short cut and now it is time to move into the full solution, any number of reasons. My belief is that Software Debt should be accounted for and used as a business management metric the same as feature delivery against market goals are measured. If you are going to spend the time within Product Management and Product Ownership in calculating the ROI for features, simplified here as:

Potential Sales over x period / cost to produce(Investment) = ROI

Then you should also calculate your current software debt burden and what the new feature will add to it:

(Number of defects existing + Projected Number of Defects with new feature) * Average cost to fix = Software Debt Value

(Yes these numbers can be subjective and so are the numbers for the normal ROI calculation used by Product Owners for features. For those of use with the Meyers-Briggs NT profiles we need to get over it, by the time you have hard numbers scientifically proven it will be too late the business will have moved on. Leave you with a pile of Software debt needing to be dealt with.)

The post Software Debt – Do you know the health of your ‘Camel”? appeared first on Leonardo da Vinci Rocks.