Search Results
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.
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.
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 Nine Transformative Aspects of the Technical Debt Metric
- The technical debt metric enables Continuous Inspection of the code through ultra-rapid feedback to the software process (see Figure 1 below).
- It shifts the emphasis in software development from proficiency in the software process to the output of the process.
- It changes the playing fields from qualitative assessment to quantitative measurement of the quality of the software.
- It is an effective antidote to the relentless function/feature pressure.
- It can be used with any software method, not “just” Agile.
- It is applicable to any amount of code.
- It can be applied at anypoint in time in the software life-cycle.
- These seven characteristics of the technical debt metric enable effective governance of the software process.
- The above characteristics of the technical debt metric enable effective governance of the software product portfolio.
Figure 1: Continuous Inspection
How to Use Technical Debt Data in the M&A Process
http://www.flickr.com/photos/brajeshwar/266749872/
As a starting point, please read Implication of Technical Debt Uncertainty for Software Licensing Negotiations. Everything stated there holds for negotiating M&A deals. In particular:
- You (as the buyer) should insist on conducting a Technical Debt Assessment as part of the due diligence process.
- You should be able to deduct the monetized technical debt figure from the price of the acquisition.
- You should be able to quantify the execution risk (as far as software quality is concerned).
An important corollary holds with respect to acquiring a company who is in the business of doing maintenance on an open source project, helping customers deploy it and training them in its use. You can totally eliminate uncertainty about the quality of the open source project without needing to negotiate permission to conduct technical debt assessment. Actually, you will be advised to conduct the assessment of the software prior to approaching the target company. By so doing, you start negotiations from a position of strength, quite possibly having at your disposal (technical debt) data that the company you consider acquiring does not possess.
Action item: Supplement the traditional due diligence process with a technical debt assessment. Use the monetized technical debt figure to assess execution risk and drive the acquisition price down.
http://www.flickr.com/photos/tantek/254940135/
____________________________________________________________________________________________________
Negotiating a major M&A deal? Let me know if you would like assistance in conducting a technical debt assessment and bringing up technical debt issues with the target company. I will help you with negotiating the acquisition price down. Click Services for details and contact information.
____________________________________________________________________________________________________
Implications of Technical Debt Uncertainty for Software Licensing Negotiations
A few years ago, my friend Sebastian Hassinger characterized the state of affairs in enterprise software by the following chart a la Christensen:
The key point this charts gets across is that Open Source Software is becoming “good enough”. It has already met or will soon be meeting the minimum requirements of the enterprise customer. By so doing, open source software will steadily gain ground from traditional enterprise software vendors.
Consider this chart from a buyer’s perspective. Functionality (the vertical axis in the chart) can be thought of as value. Whatever the value might be, it is diminished by technical debt in the software as the debt manifests itself as application crashes, degradation of performance and possible corruption of customer data. Everything else being equal, an application with lower technical debt per line of code is preferable to an application with a higher technical debt per line of code.
Traditional enterprise software vendors do not typically provide the technical debt data for the applications they sell/license. In contrast, a customer can carry out his/her assessment of technical debt straight off the open source code. For example, colleague and friend John Heintz carried out the following technical debt analysis on the Cassandra open source project:
As demonstrated in this chart, any customer can measure the level of technical debt in an open source software he/she considers. For better or worse, there is no uncertainty about the amount of technical debt the customer will need to live with in an open source software. In contrast, a customer will usually need to live with uncertainty about the level of technical debt in proprietary software.
Uncertainty has economical consequences. For example, testing a product increases its value because it decreases operational uncertainty. The economical value of uncertainty about technical debt is conceptually depicted in the figure below in which value is adjusted in accord with the knowledge or lack thereof of the amount of technical debt. Please note that the following equation holds for the various intersection points on the Enterprise Customer Requirements line: {T3-T2} < {T1-T0}. What this equation means is that under conditions of uncertain technical debt open source software is becoming more attractive than proprietary software faster than it would without taking technical debt uncertainty into account.
Action Item: Before licensing an enterprise application or renewing an existing license, ask the vendor for technical debt data for the application and the plans to reduce the debt. If the vendor refuses to disclose this data or can’t generate it within a reasonable amount of time, ask for the number of open bugs against this application in the vendor’s bug data base. Use either kind of data to drive down the price. Consider an open source solution (even if it provides less functionality than the proprietary software product) if the vendor you are dealing with refuses to disclose either the technical debt data or the number of open bugs in the enterprise application.
____________________________________________________________________________________________________
Negotiating a major enterprise software deal? Let me know if you would like assistance in bringing up technical debt issues with the vendor to help with negotiating the price down. Click Services for details and contact information.
____________________________________________________________________________________________________
The Agile Executive 
