Developers are from Magrathea, Customers are from Ursa Minor Beta

From the na├»ve view of an average enterprise software developer, the situation today is a bit insane. Most customers will always choose more functionality and faster delivery over testing and documentation – not to mention GUI polishing. They will look you in the eye, tell you that they sincerely understand the software will have problems once it is live, and then come back furious when the software does not work. As if we were not all speaking the same language, somewhere the meaning of ‘it will have problems‘ gets lost in translation. Or maybe it’s not the definition of ‘problems‘, but the definition of ‘done1, or maybe developers and customers really come from different planets.

Whatever the reason, from my experience the developers (and the development managers) are the ones who have to stop the vicious cycle – and start delivering better. We have to acknowledge that ‘just get it done as soon as possible, and we’ll test it on production‘ does not mean the same thing for us and for the customers. For most customers, that means that they can live with a few minor problems, but for developers this is typically a green light to shoot fireworks all around. Someone has to take the responsibility for closing this gap, and I am afraid it is not going to be the customers.

And ‘I told you so‘, when the customer comes back unsatisfied with the delivery is not really an option – not if you want to keep them. Even if they are reasonable more than the average, and you win that argument, you will be losing much more – as your reputation will suffer. Somewhere in the back of their minds, customers will feel cheated, even if they do not say that out loud, and you just lost a credit point.

Sprinting is futile if you crash

Sprinting to add raw, unpolished functionality almost never pays of, and it can blow up in your face. I learned this the hard way three years ago, while working on an on-line casino project2. We developed much faster than we initially estimated, and the software was ready for delivery before the layout design was finished. We decided to deliver the software early, hoping to make a good impression on the clients, but the exact opposite happened – clients hated the mock-up layouts so much that they wanted to cancel the entire project. It took a lot of effort, mostly painful politics, to convince them that the project should continue.

As a different example, when I worked on an ERP system, we underestimated the effort required for the first iteration. There were two options: we could either deliver all the planned functions, but the software would probably be unstable and quite buggy; or, we could deliver about half of the planned functions but polish them. The clients wanted the system up and running as soon as possible (as always), and they pressed for functionality, asking for earlier delivery even if it throws fireworks. However, knowing that it was really important to make a good first impression on a new client, we decided not to pursue the functionality, but to cut it in half and do it properly. The result was quite good – they were happy with the first cut, not so happy about the prolonged schedule, but the way the system worked and looked like gave them confidence that we knew what we were doing. Had we delivered more functionality, like they asked, I’m pretty sure that we would have lost the contract soon after the first delivery, or at least have to go through a political hell of explaining who requested what, who was warned and who acknowledged warnings. On the end, there is only one first impression – if you miss that one, it’s a lot harder to establish trust and confidence afterwards.

Why bother, after all?

Hmm… How to start explaining the benefits of happier customers? More work, better relationships, more money… And sometimes you might really get away with murder. Mistakes do happen, and in a long term engagement some big problem is bound to come up. That is the moment when you really need the customer to think ‘well, these guys were pretty darn good so far, and what they suggest seems reasonable, so let’s give it a chance‘ and not ‘those stinking %^$&#* have gone too far, and now they want to shut down the production for 10 hours. memo to self – call the others and let’s start planning a migration on Monday‘. To have a lucky break, and customers’ support, you need to have credibility – yet delivering unpolished software again and again slowly slices pieces of credibility from the reputation of development organisations. Once lost, the credibility is hard to recover. Save it for the rainy days, when you will really need that ‘get out of jail free‘ card – don’t throw it away with unpolished releases.

It’s all in prioritisation

If you deliver regularly, and often, most customers will not mind too much if the project actually takes longer then initially estimated. Even if they do mind, it’s the lesser of two evils. If there is not enough time (or from a different, less fatalistic, perspective – there is too much work) it’s mostly better to deliver less, but better polished, than more, no matter what the customer will tell you in his Ursa Minor Beta language. (‘Mostly’ means that there are exceptions, of course – and again developers and development managers are the ones that have to recognise them). Pressing for non-realistic schedules does no good, and it can actually turn the project into a death march3. Agile development techniques can help in this situation, as the client should be involved in planning. Even if you are not using agile methods for development, talk to the customers and get their priorities – most of the time they will be happy to get high-priority features now and get the rest a bit later, if it all works good and their goals are met4. I’ll borrow a quote from Getting Real5: It’s better to make half a product than a half-assed product.

Finishing touches

No fireworks on production:
The software must not scare users by crashing, or printing stack traces and raw SQL errors – it’s much better to deliver less functionality but properly polished than more functionality that blows up. From my experience, the first option tells the customer that the project might be more complex than initially expected, but the second gives them the impression that developers are incompetent since the software crashes.

No mock-up layouts:
Avoid showing mock-up layouts, especially if the layout is an important part of the customer experience. On the end, users only see the user interface, so it better be good.

Check positive branch manually:
Automated testing is great, but sometimes it can blind you. Make sure that the basic functionality of the system (at least the positive branch) works and looks OK from the GUI – check it by hand and with your own eyes.

No surprises:
User interface should behave, as much as possible, like standard applications. There are, of course, exceptions when an innovative user interface is the main selling point of the product – but most of the time a standard interface will do much better.

Automate installation and upgrades:
Build an automated installer, which will make sure that everything is done properly, and not require clients to manually copy and edit files. My favourite bad example is the web upgrade where the developer just sent some files along with a note ‘Please remember to configure all the parameters like we talked about over the last few weeks‘. The automated installer will make the client happier, and reduce support problems. It does not matter if your clients are technical enough to install everything by hand – they will be happier to just run a script. Creating a simple installation script will take you 30 minutes, and your clients will surely appreciate that. Nullsoft Installer6 is a great free tool for building automated installers, if you do not have the budget for commercial tools.

Provide documentation:
Release notes, a simple HTML-based help system and supporting documentation add a more serious note to the software, and should be prepared for anything except the most trivial projects. Even if everything is plainly clear and the system is intuitive (which it should be), these documents will make your team look more professional. It’s the same difference as the one between sending a letter printed on a plain paper or on a letter-headed one.

Footnotes

  1. Ken Schwaber explains various meanings of a ‘project being done‘ in the presentation A Canary in a Coal Mine
  2. My post-project conclusions about the on-line casino are described in the post Joys and Perils of Mass-Market Java Games
  3. see Edward Yourdon’s excellent book on Death March projects
  4. see The magic of Goals, Focused Projects and Better Requirements
  5. see Fix Time and Budget, Flex Scope from Getting Real
  6. see NSIS Project on Sourceforge

Image credits: Wax115/SXC, Kavitha/SXC, Nasa/GIMP Savvy

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

Product Owner Survival Camp

Specification by Example Workshop

Conference talks and workshops

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>