Follow Me

Feb 262011
 
Software Debt - Do you know the health of your 'Camel"?

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 [Read More...]

Feb 052011
 
Collateralized Technical Debt compared with CDOs

David  Knootz commented on my recent post about Technical Bankruptcy referring to an interesting thought in his blog “Technical Debit – Collateralized Debt Obligation you should not invest in.” I was just going to reply to his comment but my response got more and more involved . The CDO comparison presents a interesting thought, for me a follow-on question to David’s posting would be are some organizations already making money off of Collateralized Technical Debt – it is less expensive in the short term to miss out that finicky automated testing and unit testing stuff – unmanaged outsourcing, consultants, etc. or organizations that just spend too little time on managing technical debt. Technical debt will happen, I would say if you have removed all debt from your code before releasing it then you have spent to much time perfecting it [Read More...]

Jan 232011
 
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 analyze technical debt first from a numbers [Read More...]