Archive for the ‘Technical Debt’ Category
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.
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.
Click here for additional thoughts on the subject and its implications.
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.
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!
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
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.
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.