I was given a new technological device for Christmas that I never knew I needed – a cup warming plate that plugs into my laptop.  Now I can type away while leaving my tea or coffee for ages without it going cold.

The device has set a new standard for decadent features that I previously did not conceive a need for.  And of course it comes with a warranty if I can be bothered to log in and register.

I am happy to have this new complexity in my life as the maintenance cost is minimal.  I can either keep it on my desk, pack it in my suitcase, or stick it in a cupboard “to use later”.

I am also happy to register for the warranty “just in case”.  But I will be very annoyed if I have to actually use the warranty, because I will be really frustrated if my shiny new toy (er – I mean productivity enhancement device) doesn’t work properly.

Interestingly, though I have been speaking to some IT crews recently who insist that all IT projects should have a warranty period.

Apparently offering a warranty shows the business customers that we care and want to do the job properly.

But my question is this – If I am annoyed at having to use a warranty for the products I buy, then why should my customers be happy at having to use the warranty I give them.  Shouldn’t they be like me, sticking the warranty in a file in case of need and then forgetting about it?

I recently added an article to another blog about testing, and I added a link to yet a further blog that talks about testing on agile projects.  They are slightly relevant here because they both talk around the idea that we should build quality into what we do rather than testing and fixing what we produce at the end.

You can follow the links here if you like: http://softwareeducation.wordpress.com/2009/12/27/some-holiday-reading-what-happens-to-testers-on-agile-projects/

More importantly though, the lesson I would like to take from the new coffee warmer I have is Not that we need more complexity, gadgets and features that nobody previously realised they needed.

It is that we need expect our systems to work. We should be surprised if they fail and therefore “warranty periods” should be an accommodation to the past practice of building too much complexity too quickly. If our clients want to purchase a warranty then fine – but we should use the chance to hang out with production support and fix old bugs, not start to unwind the damage done by our latest period.

Then the measure of a successful project can be that the clients start to see warranty as paperwork to stick in the draw.  And we can get on with building the next thing they want.