Ward Cunningham in 1992 coined the term “Technical Debt” to describe something done (or not done) during the software development process which will require to be worked on in future, possibly at a higher cost. For example, I write a nice new class but do not do any refactoring or unit testing. In 6 months I do not touch this class before then having to use it in a new piece of functionality. Changing this class can then cause a myriad of problems for the system, and so I am paying a lot more for the work than if I had invested some time before hand.
I recently read a blog post Steve Freeman wrote entitled “Bad Code isn’t Technical Debt, it’s an unhedged Call Option”. I really liked this idea for a number of reasons. Firstly, it is a bit nicer to play around with mathematically (more on this later) and secondly, as his brilliant post describes, it is a far better analogy for what we are really talking about. I also like this viewpoint however because it counteracts the way we consider debt in western society. We see debt as something that is acceptable as long as it is managed, and we consider it fixed and managed. We can pay the debt of incrementally when we wish and there is a pretty (generally) small interest rate and linear growth pattern. This as anybody who has worked on a piece of software for more than one version will tell you is certainly not true of “Technical Debt”.
Whilst at university I studied a couple of semesters worth of lectures on financial mathematics and I remember learning about call and put options as well as their involvement in a portfolio (and stochastic processes in some situations). As is natural then, Steve’s post got me thinking, if technical debt is a call option, then what analogously is a put option and can we consider our software development project to be somewhat similar to an investment portfolio? (Here we begin to stray into some wonderful theoretical musings on software development as a complex non-linear dynamical adaptive process. But we shall save that for another day.)
Firstly, let us clarify a few things. The underlying asset I am describing here for our call or put option is effort, which we can measure in hours, story points, bananas or any unit of work that it takes to develop a piece of software. Obviously this itself is a loose concept, as the effort on a piece of work varies through the project lifecycle, but we will use it as it is a concept we can understand.
Taking a call option out on this is then a management process:
“Management will pay a premium up front (in terms of hours of testing for stability or extra documentation/customer support) to take out a call option on a piece of code, hoping or betting that the price of effort to work in that area has not risen too high if the option is exercised (they wish to work in that area with new functionality again).”
If such an analogy is true then we can use the notion of a put option to be the following:
“We pay a premium up front (in terms of effort spent refactoring, unit testing etc.) to take out a put option on a piece of code, expecting that the price of effort to work in that area will rise to make the premium paid worthwhile (effectively negated).”
If this is a correct viewpoint (which I believe is logically sound) then we can consider our project or work on a piece of code to be somewhat similar to managing an investment portfolio by buying a series of different put and call options to achieve the maximum return on investment with the minimum risk available. We will want to do as much work as possible in making the software stable and extensible later on (put options) yet we understand that there is always some risk taken when having any software.
I would love to be able to determine some sort of price for code smells (or use a rough story points estimate based upon some team values) to see how best a portfolio could be managed. I have spent some time already on paper messing about with this, and will hopefully sometime be able to jot something up here. I was also looking into modelling agile as a crude non-linear dynamical system, so don’t expect anything too soon ;-)