We all want more, right?

We always want more – or do we? As a software developer I was always keen to go the extra mile and put something on the screen that will just WOW the person who would use my software. Unfortunately it usually WOW’ed me and not them. And more often than not it would take some time to create. Now, as a consultant I see evidence of this ‘practice’ all over.

Imagine a spec for a Title field that says there must be a drop-down list with all titles currently in the database. The hardworking developer with the best of intentions decides to find a source of all possible titles ever. The result?

As a customer I can tell you that I don’t need a list of 50 to choose from, and neither do the 2 people whose title *might* be “Her Serene Highness”. Though, of course, when I saw this particular list, I had to select “Her Serene Highness” and I cannot wait to get my first correspondence letter 🙂

A few years ago I coached a Product Owner and said to him “Beware of free candy”. Developers love telling you they can do this one little extra thing that will make it so WOW and its quick, easy, *free*. Nothing is free. If your developers are doing this then they are lying to themselves and to you. That particular PO surprised me often in grooming by saying to the developers “No thanks, I don’t want free candy”. I think it helped that he was an ex-developer and so could recall when he had made those promises.

It’s usually simple little things like “oh, what about rounded edges on the square box?” and it’s not just developers. Analysts do this all the time as well. I think its human nature to want to please and do something special and extra. The problem creeps in slowly… when we’ve done all this gold-plating when all the customer wanted was stainless steel… and they wanted it last week.

Our favorite agile principle is:

[pullquote1 quotes=”true” align=”center”]Simplicity is the art of maximizing the amount of work not done[/pullquote1]

Here is a nice blog post explaining this a bit more. How many little things do you add – on the screen, in the code base, in your documentation, in the design – that do not contribute to your sprint goal or acceptance tests?

There is a concept called Software Bloat, and a bunch of statistics (usually attributed to some older Standish Chaos Reports) that over 60% of functionality delivered is rarely or never used, a tremendous waste of development and support funding. Sound familiar?

So how do we stop doing this?  One way is to have your Product Owner recognise when gold plating is happening and have them say “no” to the free candy. Another is to use Test Driven Development. Write your test cases first. Then write just enough code to make the test pass. No more. Refactor, and throw away code you no longer need. Remember that every line of code you add needs to be maintained. Someone will have to read it, understand it, compile it, test it, and you are wasting their time if you don’t remove it. Another idea is to log when customers use certain features: that way you can track unused features and remove them.

I recall a story of a company that bought another company and took over their source code. All comments were in a foreign language that no-one could understand, and yet no one removed the comments. Why? Well, because perhaps one day someone who understands the language will work there and find them useful.

Stop peddling free candy. Stop gold plating. The world will be a better place, with much smaller title drop down lists.

I will miss my new title of “Her Serene Highness” though *sigh*