The Agile Executive

Making Agile Work

Archive for the ‘Technical Debt’ Category

When Technical Debt Meets “Life”

leave a comment »

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.

Advertisements

Written by israelgat

December 18, 2011 at 2:04 pm

Reflections on Due Diligence

with one comment

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.

Written by israelgat

November 27, 2011 at 9:51 am

Delving into Technical Debt

leave a comment »

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.

Written by israelgat

October 31, 2011 at 7:28 pm

Technical Debt: Assessment and Reduction

with one comment

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

Getting Ready for Agile 2011 – Part II

leave a comment »

In her recent post Getting Ready for Agile 2011, Anne Mullaney gave an outline of my forthcoming sessions at the conference. Specifically, she highlighted the emergence of new forms of Agility:

“Super-Fresh Code” is a term Israel coined (an extension of the “Super-Fresh Web” concept) to describe code that results from seizing upon the opportunities opened by combining recent advances in Agile software methods, cloud computing, mobile applications, and social networking. With the right mix, a company can outgun, outclass and outmaneuver its competition through real-time requirements management and superior business designs. Essentially, super-fresh code becomes the source of competitive advantage. This is a workshop that will make you think about Agile in ways you never have before.

Appropriately enough for the anniversary year of the Agile Manifesto, my strong conviction indeed is that we are just about witnessing Agile going beyond being “just” a software method. Markets are becoming hyper-segmented. There is no way to reach tiny, granular market segments economically without sophisticated software. Moreover, markets are becoming ultra-fluid. It takes a high degree of software-based business agility to penetrate market segments that form and collapse at the speed with which social networking groups emerge (and disappear). Hence, software is becoming a bigger and bigger part of just about any business — avionics, financial services, healthcare, retail, transportation, telco, and so on. In fact, in many engagements Cutter consultants carry out, the software is the company. Unless Agile methods are used strategically, the ability of a company to generate value for its customers and capture profit for itself might be in jeopardy: the company simply cannot adapt fast enough in the face of a significant amount of technical debt.

Viewed from this perspective, technical debt becomes an integral part of Agile methods. One starts an enterprise level Agile roll-out in order to, well, gain Agility. The accrual of technical debt puts a damper on Agility. Hence, implementing a technical debt assessment, reduction and prevention program is an essential part of the Agile initiative. In fact, Cutter recommends to its clients to integrate the two all the way down to the backlog stories.

I can’t wait to discuss these topics with you and other Agile 2011 participants in just about two weeks!

Surfing Technical Debt

with one comment

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.

Written by israelgat

December 26, 2010 at 9:52 am

SPaMCAST 112 – Israel Gat, Technical Debt

leave a comment »

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.