insurance for software defects

The more I think about it, the more astonished I become. Maintenance contracts for (bespoke) software: Buying insurance to cover against the possibility that the software doesn’t work.

I know the consumer electronics industry does the same, and I always baulk at the idea of spending an extra fifty quid in case the manufacturer cocked up. I wonder what percentage of purchasers buy the insurance? And I wonder what percentage of goods are sent back for repairs? Perhaps the price could be increased by 10% and all defects fixed for free. Or perhaps the manufacturer could invest a little in defect prevention.

It seems to me that software maintenance contracts are an addiction. Software houses undercut each other to win bids, and then rely on the insurance deal to claw back some profits. So no-one is incentivised to improve their performance, and in fact the set-up works directly against software quality. Perhaps it’s time now to break that addiction…

If a software house were able to offer to fix all defects for free, would that give them enough of a market advantage to pay for the investment needed to prevent those defects? Is “zero defects or we fix it for free” a viable vision? (Does any software house offer that already?) And how many software companies would have to do it before the buyer’s expectations evolved to match?

As an industry, do we now know enough to enable a few software houses to compete on the basis of quality?

10 thoughts on “insurance for software defects

  1. Yes indeed. The problem doesn’t seem to be there for commoditized consumer goods, but for bespoke software it’s a real issue. So in order to get to “we fix it for free” a software team would have to look very carefully at customer involvement / feedback / collaboration: acceptance tests, regular reviews, all the usual “agile” yada yada. For real.

  2. In practice, we provide this service to our clients. Where we’re generating most of the code using a well tested framework it works out pretty well (although we have documentation differentiating defects from unexpected or unconsidered user cases, user inputs, etc.). As the projects become more complex and truly custom, it becomes more of an issue, so I’d be interested to hear how anyone else doing this mitigates their risk (other than just by adding a contingency cost to each project).

  3. Since you reference my article on Viable Vision, I figure I should respond.

    The claim of Theory of Constraints is that with a focus on doing the right things, quality goes up naturally. (The focus isn’t on “zero defect” or whatever, it is on making sure the constraint is doing the things it (they) should be doing. One of those activities includes making sure the constraint doesn’t work on crap that will have to be thrown away later — time wasted on the constraint can never be recovered.


  4. Hi Jack,
    Agreed – defects will disappear via thorough application of either lean or TOC principles. But the software development world seems to be addicted to defects, for some reason. So much so that the existence of defects in software has become an accepted norm. I’m interested in why that delusion perpetuates. And I’m interested in the possibility of competing on the basis of shredding it. Would a zero defects shop dominate the market? I think so, and that would be mostly due to the fact that zero defects would only be possible by doing everything else right, as you say.

    And yet, the existence of maintenance contracts, and their use to reclaim profit from bidding wars, creates a barrier to accepting these notions. How do I persuade a software house CEO that having the customer pay for defect fixing is an addiction with negative consequences for everyone?

    Thanks for encouraging me to think through this. I guess I need to turn all of this into a conflict cloud and get my thinking hat on…

  5. Software being a human activity, I don’t think that defects will disappear one day. If we consider Toyota and its lean car production system, this does not make defect disappear, but however will limit intervention on the car during the time of its warranty. Thus promising zero defects would not be a good business claim, but having an extended warranty period on the software and making corrections for free could allow to win contracts over higher maintenance fees. Toyota needed however a lot of time before gaining its reputation and being a market leader… and I think that they still need to compete on price.

    • Hello old article.

      There may be economic considerations. Lets say your project traditionally costs 100k. You pay 50k up front and 50k on completion and a maintenance contract of 2k/y for 5 years. Even if you pay the 10k extra on contract completion then you still have to release that capital early many people like the option.

      It may not be the development team’s fault. Even if all the stars are aligned, external factors, like OS support going away (e.g. Win XP) or change in business compliance rules can mean that change is inevitable. Cutting the ties is a risk.

  6. I have been involved in two bigger-scale deliveries where there were zero-defect policies, in both cases the “free bug fix” demand came from the customer. Once I was the supplier, the other time I was part of the customer (but innocent in the contractual crime, I’d like to state).

    As a supplier there are two ways you can deal with such a demand from a customer, I advocate to use both.

    a) You can estimate worst-case situations and ensure that you charge enough up front so you’re still making profit even when there are a lot of such free fixes. This strategy can’t always succeed, but it should keep you financially healthy enough to survive even bad cases when they happen, as you usually will make above-average profits.

    b) You make the customer part of the quality effort (I assume you do this agile given the blog, i.e. such testers being involved from the start). In this case, you will only be held liable for serious and obvious bugs, i.e. stuff your own QA should have caught. If the issue is “not exactly the behaviour we wanted”, you can refer to the customers’ representative having accepted it and hence it cannot be seen as a bug.

    Truly, if you’re faced with a customer who wants such a policy and you can afford it: run. I am convinced that a customer who asks for free bug fixes harbours a deep routed blame culture (these are mutually attracting mindsets). Where that’s the case, the customers’ individuals are not interested in delivery of value, but in how to cover their backs. They will assume you are applying strategy a) and accept that they pay such a premium for the luxury to blame you for all their (managerial) failures. You can profit from this in the short term, but their attitude will prevent a constructive relationship, i.e. they are poisonous customers. (This can also be very demotivating for your staff!)

    As to why you want to offer such a policy as supplier voluntarily, given what kind of customer you are most likely to attract with that… Greed?

    There ain’t no such thing as a free bug fix!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s