Archive for the ‘Technical Debt’ Category
When Technical Debt Meets “Life”
I will have the distinct pleasure of leading a roundtable discussion on the subject in the forthcoming Cutter Summit. Here is the general direction we will jointly explore:
A technical debt assessment is often relegated to the “strictly for geeks” category. Supposedly, no sober executive wants to hear about metrics like Afferent Coupling or Distance from the Main Sequence, let alone learn and track them. Right? Wrong! In this round table discussion, Israel Gat will lead a discussion about the “life-view” that technical debt assessments reveal. Time and time again, we find technical debt readings reflect a broader truth than just the way software is produced. Here, we’ll discuss the measures that you could, and perhaps should, apply to tie process, code and outcome together to create a sustainable equilibrium between development, operations and the business.
Reflections on Due Diligence
I still remember the reception committee from the due diligence on Tideway I did for Apax Partners some seven years ago. The folks were awesome. I am fairly certain they could convince birds to fly off the tree if they chose to apply their very many talents toward this end. I really don’t know whether Apax (who invested in Tideway) and BMC (who acquired Tideway at a later time) consider their investments in Tideway successful. But, take it from me: even the Royal Shakespeare Company would have been hard pressed to stage such a terrific act as the one played by Tideway for my benefit in 2004.
The Thing That Code Does Not Do
Click here for additional thoughts on the subject and its implications.
Delving into Technical Debt
Many of the findings and the recommendations we make in Cutter technical debt engagements are broadly applicable in concept, if not in detail. There is commonality in the nature of the hot spots we typically find, the mal-practices we identify as the root causes and the ways we go about reducing the “heat.” Granted, your technical debt reduction strategy might dictate investing in automated unit testing prior to reducing complexity, while your competitor might be able to address complexity without additional investment in unit testing. However, the considerations you and your competitor will go through in devising your technical debt reduction strategies are fairly similar.
It is this similarity that we try to capture in this Executive Update. Some of specifics we recount here might not be applicable to your environment. However, we trust the overall characterization we provide will give you, your colleagues and your superiors a fairly good “3D” picture of how the technical debt initiative will look like in the context of your own business imperatives and predicaments.
The good folks at Cutter have released the Executive Update from which the excerpt cited above is taken. It is co-authored by colleague Chris Sterling and me. For a free donwnload, click here and use the promotion code DELVING.
Technical Debt: Assessment and Reduction
Below is the detailed outline for my August 8, 1:30-5:00PM Technical Debt Workshop in Agile 2011. I look forward to meeting you and interacting with you in the conference before, during and after this workshop!
Best,
Israel
Technical Debt: Assessment and Reduction
Part I: Technical Debt in the Overall Context of the Software Process
- A Holistic Model of the Software Process
- Two Aspects of Output
- Three Aspects of Technical Debt
- Six Aspects of Software
Part II: What Really is Technical Debt?
- What’s in a Metaphor?
- Code Analysis
- Time is Money
- Monetizing Technical Debt
- Typical Stakeholder Dialog Around Technical Debt
- Analysis of the Cassandra Code
- Project Dashboard
Part III : Case Study – NotMyCompany, Inc.
- NotMyCompany Highlights
- Modernizing Legacy Code
- Error Proneness
Part IV: The Tricky Nature of Technical Debt
- The Explicit Form of Technical Debt
- The Implicit Form of Technical Debt
- The Strategic Impact of Technical Debt
- No Good Strategy Following Prolonged Neglect
Part V: Unified Governance
- How We View Success
- Three Core Metrics
- Productivity, Affordability, Risk
- What is the Real ROI?
Part VI: Process Control Models
- A Typical Technical Debt Pattern
- Process Control View of Scrum
- Integration of Technical Debt in the Agile Process
- Using Statistical Process Control Methods
Part VII: Reducing Technical Debt
- A Framework for Thinking about and Acting on Technical Debt Issues
- Portfolio Governance
Part VIII: Takeaways
- Nine Simple Takeaway
- Connecting the dots
Surfing Technical Debt
The Second Workshop on Managing Technical Debt will be held on May 23, 2011 in Honolulu, Hawaii. It is part of and co-located with the 33rd International Conference on Software Engineering (ICSE2011). Between the workshop and the conference you can rest assured any aspect of software engineering known to mankind will be amply covered.
The workshop is quite unique in its strong emphasis on rigorizing the foundations of technical debt and unifying the ways in which the generic concept is being applied. The reason for so doing is quite straightforward. The term ‘technical debt’ has, no doubt, proven intuitively compelling. The various intuitive interpretations, however, differ in various subtle nuances. The Overview of the workshop points out:
Yet, it leaves many questions open, such as
- How do you identify technical debt? What are the different kinds of debt? What are its parameters that help projects elicit, communicate, and manage it?
- What is the lifetime of technical debt?
- How is technical debt related to evolution and maintenance activities?
- How can information about technical debt empirically be collected for developing conceptual models?
- How do you measure and payoff technical debt? What metrics need to be collected so that key analysis can be conducted?
- How can technical debt be visualized and analyzed?
As readers of this blog know, I love the combination of intellectual challenge with pragmatic utility that characterizes technical debt. Doing technical debt in Hawaii adds a dimension of pleasure to the mix. The mental image I have for the workshop is ‘Surfing Technical Debt.‘
On a more prosaic note, the due date for submitting a paper to the workshop is January 21, 2011. Please do not hesitate to contact me or other members of the program committee for any questions you might have on your paper.
SPaMCAST 112 – Israel Gat, Technical Debt
http://www.flickr.com/photos/pumpkinjuice/229764922/
Click here for my just published interview on Technical Debt. Major themes discussed in the interview are as follows:
- The nature of technical debt
- Tactical and strategic effects of technical debt
- How the technical debt metric enables you to communicate across levels and functions
- What Toxic Code is and how it is related to Net Present Value
- The atrocious nature of code with a high Error Feedback Ratio
- Cyclomatic complexity as a predictor of error-proneness
- Use of heat maps in reducing technical debt
- Use of density of technical debt as a risk indicator
- How and when to use technical debt to ‘stop-the-line’
- Use of technical debt in governing software
To illuminate various subtle aspects of technical debt, I use the following metaphors in the interview:
- The rusty automobiles metaphor
- The universal source of truth metaphor
- The Russian dolls metaphor
- The mine field metaphor
- The weight reduction metaphor
- The teeth flossing metaphor
Between the themes and the metaphors, the interview combines theory with pragmatic advice for both the technical and the non-technical listener.
A Special Technical Debt Offer from the Cutter Consortium
The good folks at Cutter are making the October Issue of the Cutter IT Journal (CITJ) available to anyone who is interested in getting deeper into the intricacies of technical debt. Here is the table of contents for this issue:
- Opening Statement by Israel Gat
- Modernizing the DeLorean System: Comparing Actual and Predicted Results of a Technical Debt Reduction Project by John Heintz
- The Economics of Technical Debt by Stephen Chin, Erik Huddleston, Walter Bodwell, and Israel Gat
- Technical Debt: Challenging the Metaphor by David Rooney
- Manage Project Portfolios More Effectively by Including Software Debt in the Decision Process by Brent Barton and Chris Sterling
- The Risks of Acceptance Test Debt by Ken Pugh
- Transformation Patterns for Curing the Human Causes of Technical Debt by Jonathon Michael Golden
- Infrastructure Debt: Revisiting the Foundation by Andrew Clay Shafer
Being the guest editor for this issue, I can attest better than anyone else how much I learned from the various authors, from Karen Pasley (the October issue editor) and Chris Generali (CITJ Editor-in-Chief).
Click here for details of this special offer including downloading instruction.
Agile Enterprise Forum 2011
Charles Handy, Chris Potts, Don Reinertsen, John Seddon and I are the featured speakers in the Agile Enterprise Forum 2011. The Forum will be held on March 10, 2011 in the Chandos House at the Royal Society of Medicine, London. Attendance is limited to 30 CIOs.
The theme for the forum is Agility for Complex Organizations. The overarching message is nicely captured in the following summary by James Yoxall:
There are two strands of interest for a CIO: strategy and delivery. The Agile/Lean message can be summarised as “merging” the two, so that delivery can start before strategy is complete, and delivery informs strategy through feedback loops. This leads to a faster/earlier delivery and a better end result.
My own workshop – Agile Governance: Tying Delivery to Value – builds on this message by describing a specific strategic initiative which is not achievable without the use of advanced delivery techniques. Here is the abstract for my workshop:
This workshop will explore mechanisms for unlocking the full potential of existing software through the combination of Agile/Lean methods with technical debt techniques. These mechanisms apply to complex organisations that rely on in-house development teams as well as to third party delivery partners. Israel’s approach emphasizes the need to continuously monitor and mitigate the decay of software that more often than not had been developed over many years. Most importantly, it shows how well-governed software can become the enabler for unleashing the synergistic power of cloud, mobile and social.
You can think of the workshop as linking past, present and future. The “sins” of the past require technical debt reduction initiatives today. These initiatives utilize the classical Agile/Lean techniques of continuous measurement and tight feedback loops. Without such initiative, the value of existing software cannot be unlocked in the future. In particular, competing in the hyper-segmented markets that cloud, mobile and social generate will be next to impossible for legacy software that has not been modernized.
Jim Highsmith on the Financial Implications of Technical Debt
Jim Highsmith launched his new blog/website last week. I have no doubt whatsoever it will be a thought leadership blog. Moreover, knowing Jim I would expect the blog will address and integrate concepts and ideas from numerous disciplines, not “just” from software methods.
Jim’s first publicly available post – The Financial Implications of Technical Debt – explores the impact of technical debt on capitalization. To quote Jim:
So the bottom line for technical debt. It’s expensive to fix, but much more expensive to ignore. Technical debt reduces future earnings, but even more critically, it destroys predictability which in turn impacts market capitalization in the near term, not in the future.
http://www.flickr.com/photos/johnwardell/80125882/
Figure 1: Loss of Predictability
Jim’s post nicely closes the {financial –> technical –> financial} loop. Ward Cunningham’s original debt metaphor borrowed the financial term to apply it to software development. Jim is now bridging from the technical arena back to the financial world.
If you are into any form of agility – technical, managerial or business – you owe it to yourself to follow Jim’s blog.
The Agile Executive 
