Why Clients Lie (And What to do About it)
As developers, we want to get clients and users involved in the software design process early and often (so-called “Participatory Design“). There are several reasons often trotted out for this:
- It helps us find problems earlier
- It helps better define the problem domain
- It clues us in to incorrect assumptions
- It makes clients feel all good inside
The problem is that this model makes an (incorrect) assumption that clients will actually be able to identify problems in pre-release software. Even if you have very technically adept clients, it is unlikely that they are familiar enough with your software to recognize serious architectural problems that may exist. More likely, you have a client that knows just enough to be dangerous, or isn’t really technically proficient at all. It’s a rare client indeed that can give you a succinct list of tasks that correspond to actual code changes. That’s okay, if everyone were as proficient as you, you’d be out of a job, right? *wink*
An even bigger problem is that most clients were raised right by their mom and dad, and they won’t insult your software to your face. At least, not until they’ve paid for it. It’s like if your friend buys a new car. You don’t tell him it’s a piece of junk, even if it is. That would just be rude. So the issue here is that clients will intentionally avoid pointing out problems in pre-release software. Once they’ve paid for the software (which is full of problems that weren’t pointed out before the release), you’ll then be bombarded with change requests and bug reports. Because, once you buy a piece-of-junk car, you have permission to complain about it to everyone. After all, you paid for it. Either that or you have a client that claims to hate everything you do (maybe he was raised by wolves or something). No matter which, you have the same problem, which is that you have no idea if what you’re doing is going to be good enough or not.
This is the state of most big projects: software coded to incorrect specifications written by non-technical clients who won’t point out problems in pre-release software because they want to be nice. This is why every software engineering lifecycle, even the most naive of waterfall models, is iterative.
But there is a way to alleviate the problem to some extent. We should try to get our clients to act right, but we have to help them. Software engineering is as much about people as it is about code. We can’t give our clients an impromptu technical education to get them to recognize technical problems in our software. So, we have to help them uncover the problems during pre-release for us, without relying on them to draw any conclusions whatsoever or relying on them to tell us about any problems they see. The easiest way for them to do this for us is to have them use the software, early and often.
To achieve this, development should be directed towards having a functional product as soon as possible after the inception of the project. Don’t spend a month making database classes and business objects; purge the path from top to bottom and have a working piece of software, even if it only does one thing and does it poorly. The sooner it’s in the hands of the client, the sooner you’ll get feedback.
Recognize that most of the feedback you’ll get isn’t of the kind where the client calls and says: “x doesn’t work.” As we mentioned above, those are the calls you get after you release. But, you will get very important feedback when the client calls and asks: “how do I do x?” If you don’t get any questions at all, it’s probably a sign that they aren’t using the pre-release software at all. It might make sense to include some kind of tracking code in the builds you’re giving out to see what features they’re using or not using. If the client isn’t using the software, you should probably find out why, before you waste a bunch of time trying to guess your way through the development process.
You don’t get this kind of feedback unless you put the software in the hands of the client and allow them unfettered access to use it to their heart’s content. You can’t achieve the same level of interaction if you just give staged demos at milestones. Clients will smile and nod and be polite, because that’s what you’re supposed to do during a presentation.
To this end, in a perfect world, we’d release something to the clients nearly every day. This may not always be possible, but it’s a goal to shoot for. It’s also a good practice to do nightly builds to resolve compilation issues as soon as they occur, so there’s at least two reasons to build your whole project every day.
