The Agile Executive

Making Agile Work

Posts Tagged ‘Uncertainty

Implications of Technical Debt Uncertainty for Software Licensing Negotiations

with 2 comments

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.



A Question of Correctness

leave a comment »

Colleague John Heintz brought up a question about the the post Uncertainty, Complexity, Correctness. To quote John:

How are “uncertainty” and “correctness” related?

Doesn’t uncertainty mean my definition of correct may change? Could I have totally correct direction, but still have uncertainty?

What gives?!?

John is referring to the way I try to pinpoint the exact “pain” Agile is expected to address by an executive considering an Agile implementation. Specifically:

Agile is all about effectively addressing uncertainty, I say. I stress that Agile does not address complexity per se. It might indirectly help with complexity if it leads you towards deeper thinking about Complex Adaptive Systems. For example, you might consider evolving the product architecture in the course of your Agile project instead of pre-defining it. However, Agile is not a “medicine” for complexity pains.

Nor is Agile about correctness. A hyper-productive Agile team could actually go fast nowhere implementing a poorly conceived product. The “real time” feedback  loops of  the project team might help uncover that a product is mis-conceived. However, independent of the team feedback, you still need to determine what correctness means to you and how you would assess it as the product evolves.

The answer to John’s good question is that correctness is a matter of the level of abstraction as defined in Hardware Engineering: A DEC View of Hardware Systems Design. Suppose you are coding a service enabling passengers to check in for flights. At the functional level, the correctness of the coded service is fairly unambiguous and (hopefully) will be established through testing. The check in service might be correct functionally, but still subject to change. For example, an airline could aspire to enable its passengers to check in through any mobile device whose volume of sales exceeded one million units. Such an aspiration will necessitate fairly frequent changes to support new mobile devices as they cross a threshold of popularity.

So, yes: one could have a totally correct direction, but still have uncertainty.

Written by israelgat

May 1, 2009 at 5:11 pm