The Customer is Always Right

In many businesses the maxim “The Customer is Always Right” is often a reasonable way to retain a strong client base. It works best when the transactions are small and there is an expectation of repeat business. It also helps with ‘word of mouth’ situations, where many of the customers talk to one another. In the very worst case -- there are always people out there who feel compelled to take advantage of any situation -- you have to refund an item or two. Not a big loss in profit if it helps keeps business stable.

In software however, we are dealing with extremely long running projects. Most things have to be done in the correct order, and they have to be done well enough. Any earlier short-cuts manifest themselves in increasingly dangerous ways. Running a project by saying “Yes, yes, yes” to every and all requests is pretty much a death sentence. There are some things you just can’t do without negative consequences.

It’s always nice to please people and nobody wants to be the bad cop that says “No, it can not be done” or “If you do that, bad things are going to happen”, so it isn’t unusual to encounter projects in grave trouble because the people leading them cannot face up to their customers. They’ll give you plenty of excuses, but they are unaware of their own complicity.

If someone asks you to build them software then it is implicitly understood that a) the software shouldn’t suck, b) it shouldn’t take forever to build it and c) your expertise is required (or they could do it themselves). These are inherent universal requirements, they are true of each and every project no matter what is being built.

Few non-technical people are consistent or rigorous enough to be able to fully specify and understand software down to the depth necessary to write it. Thus change of direction, muddled thinking and indecision are frequent behaviors that are encountered with customers. But it is important that this turmoil at the customer level not filter down into the process of building the system. Software can’t be reactionary, it is a long slow process that involves grabbing each piece, one at a time from start to end, and getting it completed. Some design elements can be delayed in the process, and there is some flexibility in the long-term direction, but ultimately in order for the software to be released, it has to be written and tested first.

A project that is ping-ponging between arbitrary customer requests is one that is effectively putting too many balls into the air all at the same time. Not only is this increasing the inefficiency of the work by a significant margin, it is also increasing the risk that some, or many of these balls will get dropped or forgotten until it is too late. In the chaos of development getting these balls out of play as soon as possible by getting them completed is far more significant than how many of them there actually are. To be usable, the work needs to be done first.

So the most common failure in this regard is with the assumption that the customer is always right, and they should always get what they want. Reacting to all incoming requests is almost certainly going to cause a collision in the requirements. Enough poorly thought out “quickie” patches for instance will violate a) the software shouldn’t suck. Non-stop changes to the features or scope effectively violate b) it shouldn’t take forever. And the user demanding features, interfaces, etc. that are contrary to best practices or good working habits of professionals means that they don’t have any respect for c) your expertise.

The solution is that it is more than necessary to control the customers, and to control their expectations. This means having to have a deep understanding of their problems. This means some hand-holding, and often a lot of explanation about why some of their requests are not the right way to solve their problems. This means pointing out your expertise, many, many times if necessary. And sometimes this means having to say “No” to them, even if it is unpleasant and they are unhappy about it. On very rare occasions, this can even mean having to walk away -- there are some people that can never be pleased, so you’re going to lose no matter what you do. The alternative is to just do whatever they want, allowing the software to get into such a mess that they’re eventually going to blow up. Given that fate, it is always better to get this inevitable conflict out of the way as early as possible.

It’s nice to please people, but not at the expense of the project. Software developers are not professionals if the work they do does not live up to professional standards. Blaming poor workmanship on the customers or the environment is just a poor excuse for not mastering one of the most important skills in leading development projects. You can’t lead a project if you have no idea what needs to be done, or why it should be done one way or the other. You can’t lead a project if you defer control to other people. You can’t lead a project if you don’t know which direction to take. And you definitely can’t lead a project if you can’t control the customers long enough to get things out the door. Software projects are never reactionary.