Archive for September 30th, 2010
The Gat/Highsmith Joint Seminar on Technical Debt and Software Governance
Jim and I have finalized the content and the format for our forthcoming Cutter Summit seminar. The seminar is structured around a case study which includes four exercise. We expect the case study/exercises will take close to two-thirds of the allotted time (the morning of October 27). In the other third we will provide the theory and practices to be used in the seminar exercises and (hopefully) in many future technical debt engagements participants in the workshop will oversee.
The seminar does not require deep technical knowledge. It targets participants who possess conceptual grasp of software development, software governance and IT operations/ITIL. If you feel like reading a little about technical debt prior to the Summit, the various posts on technical debt in this blog will be more than sufficient.
We plan to go with the following agenda (still subject to some minor tweaking):
Agenda for the October 27, 9:30AM to 1:00PM Technical Debt Seminar
- Setting the Stage: Why Technical Debt is a Strategic Issue
- Part I: What is Technical Debt?
- Part II : Case Study – NotMyCompany, Inc.
- Exercise #1 – Modernizing NotMyCompany’s Legacy Code
- Part III: The Nature of Technical Debt
- Part IV: Unified Governance
- Exercise #2 – The acquisition of SocialAreUs by NotMyCompany
- Part V: Process Control Models
- Exercise #3 – How Often Should NotMyCompany Stop the Line?
- (Time Permitting – Part VI: Using Technical Debt in Devops
- Exercise #4 – The Agile Versus ITIL Debate at NotMyCompany)
By the end of the seminar you will know how to effectively apply technical debt techniques as an integral part of software governance that is anchored in business realities and imperatives.
What 108M Lines of Code do not Tell Us
Source: Nemo
Coming on the heels of Gartner’s research note projecting $1 trillion in IT Debt by 2015, CAST’s study provided a more granular view of the debt, estimating an average of over $1 million in technical debt per application in a sample of 288 applications. Between these two studies, the situation examined at the micro-level seems to be quite consistent with the state of affairs estimated and projected at the macro-level.
My hunch is that the gravity of the situation from a software quality and maintenance perspective is actually masked by efforts of IT staffs to compensate for programming problems through operational excellence. For example, carefully staged deployment and quick rollback often enable coping with defects that could/should have been handled through higher test coverage, lesser complexity or a more acceptable level of code duplication.
Part of the reason that the masking effects of IT staffs are not always fully appreciated is that they are embedded in the business design of IT Outsourcing companies. The company to which you outsourced your IT is ‘making a bet’ it can run your IT better than you can. It often succeeds in so doing. The unresolved defects in your old code plus those that evolved over time through software decay have not necessarily been fixed. Rather, the manifestations of these defects are handled operationally in a more efficient manner.
Think again if your visceral reaction to the technical debt situation described in the Gartner research note and the CAST study is of the “This can’t possibly be true” variety. It is what it is – just take a quick look at Nemo to see representative technical debt data with your own eyes. And, as indicated in this post, it might even be worse than what it looks. As Gartner puts it:
The results of such [IT Debt] an assessment will be, at best, unsettling and, at worst, truly shocking.
The Agile Executive 