Software quality defined by size of bonus?

In any line-of-business company, some end-users and senior stakeholders are focused on building and releasing important functionality as fast as possible. For these people, short-term velocity is the key attribute, as long as the software is reliable enough to give the right results at the right times - for given, often unspecified, values of "right". Crudely speaking, the quality of software is defined by the size of their bonus that year.

This is especially true in the front-office. When you're sitting next (or near) to the traders and you can see their software needs in real-time, you have a tight feedback loop. I've arrived in the morning, coded and released a business feature before lunchtime, and seen the related profit arrive that same afternoon. 

There's always a healthy tension between creating useful software as fast as possible, and creating the same software in such a way that it has various quality attributes such as comprehensibility, maintainability, security, etc. Writing software as fast as possible is technically, and sometimes functionally, risky. One term used to describe this risk is "technical debt".

But this also applies in other environments, where the pressure is to show progress as much as it is about releasing business value. Because one of the core agile concepts is based on making visible progress, your own methodology can be used against you.  

As developers and technical managers, we have to convey the concept of technical debt to these people, and make them understand the risks of not repaying that debt at regular intervals. As these people typically aren't very technical, this can be tricky. Sometimes it can be a struggle for you to explain why accumulating technical debt is bad. And sometimes it can be a struggle for non-technical stakeholders to understand the non-linearity of low quality.

As I work in banking and trading organisations, the vast majority of these people are business-savvy. They understand debt, and they also understand that debt is often a good thing - it's a tool of their business. So using this terminology often isn't effective. But these same people understand financial instruments very well, including vanilla options. I've found that using the following metaphor is usually very effective:

• Imagine that your code base is equivalent to a portfolio of options.
• Over time, you add a number of business capabilities to that code base:
• • Adding new code is equivalent to selling a call option [1]
  • If the primary attribute of the new code is time-to-market rather than quality, that call option is unhedged.
• As each business capability is delivered:
• • That's equivalent to collecting the premium for the option sale
  • You've now got money in your pocket, and that feels good (for the moment). 
• Over time, things change - so you have to change, improve, or integrate existing business capabilities:
• • Changing or integrating existing code is equivalent to the associated option being called
  • A call on an unhedged option can be very expensive - in fact, your loss can theoretically be unlimited.
• If we don't hedge our option portfolio by improving existing code over time, improving business capabilities can become very expensive.  

Of course this metaphor has distinct limits because there are several types of technical debt. Let's say that you have a slow-running test suite that you have to run several times a day. In this case, a better metaphor for the associated technical debt might be a high-interest loan rather than selling a call option. Your business stakeholders are definitely interested in understanding what's slowing them down every day (fixed cost, no risk) as well as what's costing them nothing today, but could kill them next week (negative cost because of the premium, high risk).  

[1] Selling a call option means that you're giving the buyer the right to buy something from you at a fixed price during the life of the option. For example, say you're the owner of a shop selling Xmas trees at around £50 each. Just in case you run out of trees before Xmas, I sell you an option to buy 100 Xmas trees from me at £40 each. Your option runs until 20 Dec, and you give me a premium to retain this option.

If you don't run out of trees by 20 Dec, you don't need to exercise the option and can just let it lapse. If you do run out of trees, you exercise the option and I then need to find the trees for you. If I can find the trees at £35 each, I make a nice profit. If I can only find the trees at £50 each, I've lost £1,000 (minus the premium). If I don't have the Xmas trees when I sell you the option, I'm unhedged against movements in the market price of the trees and can lose a lot of money.