The Myth of Software Support

20Nov08

I’ve been too quiet of late, and part of the problem has been this blog post, which has become something of a mental bolus. It’s time to get it out.

The title really says it all. It’s my assertion that software support, or at least big company support for enterprise customers, is a myth. Not just a myth, but a costly myth that we seem to desperately cling to for reasons that elude my understanding.

When was the last time you phoned up a major software supplier’s support desk and said ‘I’ve got a problem with your stuff – it doesn’t work like it should do’ and they came right back and said “gosh – thanks for pointing that out, we’ll get right on with fixing that, and let you know as soon as possible when the fix will be ready”? It just never happens. My typical experience seems to be modelled on the stages of grief:

1. Denial – there’s nothing wrong with our software. You must be using it incorrectly.

2. Anger – how dare you suggest we make anything other than a perfect product. It’s supposed to work like that.

3. Bargaining – we can do a fix for you, but which of your high priority feature requests for the next version are you willing to give up so that we can still make the shipping date.

4. Depression – the fix is done, but we can’t let you have it as it needs to go through our regression testing cycle. We’d much rather you lived with a broken system than give you something that’s not properly tested.

5. Acceptance – here’s your patch, it took us so long to do it that we’ve rolled it up with a bunch more and called it a service pack.

So… software support is just like grief, except you pay something like a 25% annuity for the privilege. No wonder they call it S&M ;-)

I could leave it there, and let the debate rage in the comments; but maybe that won’t happen. The blogosphere has become a surprising write only medium of late. So what do I think should be done about this?

Let’s start by looking at where good software support still happens (it does) – Open Source and startups. Startups do good support because they’re desperate to have a working product and happy customers. This is how things should be. Open Source lets you fix it yourself (if need be) or pay the original authors, or some third party that thinks they’re a bit handy with a text editor and compiler, to do it for you. There is maybe a boundary condition with Open Source, which is where enterprises pay for huge OSS S&M contracts, which I feel are just as bad as huge S&M contracts for proprietary stuff.

I think the general principle for a working system looks like fixed price pay per incident. The problem with this is that it’s victim pays; and there’s also a temptation for ‘incidents’ to be closed before they’re thoroughly resolved. However, I think it would take a LOT of incidents for any enterprise to run up a bill that looks like their present S&M bill.

The pedants amongst you will now be wanting to comment about the ‘M’ bit for maintenance being an options contract on upgrades to future versions. I know, so let’s keep the discussion about support.



4 Responses to “The Myth of Software Support”

  1. 1 lauraglu

    How much would you pay per incident? How would you like that to be billed?

    It seems that many would not like having something break, whether due to software or user error, then get charged immediately for it.

  2. 2 Chris Swan

    Good points Laura, to which there are no easy answers.

    To an extent the answer for willingness to pay is in line with present per incident models offered by software houses – the point being that if the cost is say $5000 per incident then you need a LOT of incidents to run up the sort of S&M bill faced by many enterprises with large software deployments.

    Billing is indeed a thorny problem also, as enterprises usually aren’t good at coping with unscheduled funding. In effect software companies have taken a role of being an escrow agent holding funds against possible future incidents. The heart of the question is whether they add or remove value in this role?

    The underlying problem here is that there needs to be some way to fund maintenance, patching and break/fix with the organisation providing support. To that end it’s probably worth breaking the ‘S’ away from the ‘M’.

    Maintenance can be rationalised as an options contract on future releases – http://www.onlamp.com/pub/a/onlamp/2005/07/21/software_pricing.html

    Support on the other hand is about defects in manufacture. In most other industries the manufacturer has a fairly lengthly exposure to fixing things at no fee (or at least building the cost of fixing things into the sticker price). Whilst this may not be so with software at the moment I sense a shift in the wind.


  1. 1 Banking on Ubuntu | Chris Swan's Weblog
  2. 2 The DXC Blogs – Paying for Linux | Chris Swan's Weblog

Leave a reply to lauraglu Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.