It is funny how often I find this problem, one I like to categorize as:

All users lie

Now that statement, especially in isolation, rarely garners me any friends, and tends to put people’s backs up. But please don’t hit me and read on first.

House MD

My girlfriend’s favourite series of the moment is House MD – I love it too, though just not quite as much as she does, apparently there is something really sexy about Hugh Laurie now he has gotten older and is not using his foppish English accent that I don’t get. By the way, for all you Americans, who thought he was yours, he really DOES have an English accent. But … I digress…

Gregory House is, with some variations, a perfect person to have in your domain modelling or requirements gathering sessions, he seems to have a similar categorization as me:

“I don't ask why patients lie, I just assume they all do.”

It is indeed part of human nature to lie, maybe not specifically, and maybe not intentionally, but we all do it, on a regular basis. Why should we presume our users and domain experts are any better than us?

Confirmation Bias

This recently came to mind while reading a forum thread, in which the original question and scenario didn’t seem accurate to me, and later Udi Dahan piped up with a comment:

in the environment you described, I would *probably* find ways to get the actual requirement from the business (not the solution they presented as a requirement)

Bingo. He just pinned down what I had failed to pin down earlier in the thread – or at least he indicated that he thought the scenario may have been suspect too.

I won’t pick specifically on this thread, but suffice to say, this is a situation I encounter very frequently when trying to extract information from users, domain experts or business analysts about their requirements. They by nature not only have a requirement, but they have an idea of what the solution is, and they phrase their requirements in such a way that they are suggesting the solution to you.

I won’t bore you with a lot of links here, but suffice to say, many psychological studies back up these assertions … plus I am too lazy to go searching the web for them right now – it has been a long week. (start here if you really care)

Divide and Conquer

One of the key skills in development is unravelling what is presented to you, and splitting the requirement from the solution. Udi pinned it down, when presented with a scenario that doesn’t seem right, go back and make sure you got the actual requirement, not on that had been presented mixed with part of the solution, or had been corrupted by Chinese whispers.

One of the key parts of Agile is involving users and business owners in the story planning, precisely to reduce the amount of poor translation that can happen between the business and the development teams.

Domain Driven Development takes this one step further, and brings in the concept of Domain Experts, people even closer to the problem than Agile demands.

Look For The Signs

Don’t take people’s words as gospel, not even people you trust, definitely not me. Always hold a little doubt in your mind. Question when you think something doesn’t add up, or when you think that there may be uncertainty masked in a definitive statement.

The more sure people are, the more likely it is that they are covering something up, or just want to protect you from the harsh realities of the world.

As a software developer or architect, your job is to drill down through these things, to get to the essence of the requirement. Don’t let others distract you.