Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Perceived Requirements or “All Users Lie”

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

house 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.


Posted 03-02-2009 11:20 AM by Jak Charlton

[Advertisement]

Comments

Perceived Requirements or ???All Users Lie??? - Casey Charlton - Insane World « the antfactory wrote Perceived Requirements or ???All Users Lie??? - Casey Charlton - Insane World « the antfactory
on 03-02-2009 9:02 AM

Pingback from  Perceived Requirements or ???All Users Lie??? - Casey Charlton - Insane World « the antfactory

DotNetKicks.com wrote Assume Your Users Are Lying
on 03-02-2009 12:18 PM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

ferrisoxide wrote re: Perceived Requirements or “All Users Lie”
on 03-05-2009 7:10 AM

cracker..

I've been working on the theory that most requirements are "just made up".. confirmed when we got asked to incorporate customer-relationship functionality into a data management app..

(BA Bob, if you're reading.. no offence.. I love you man, but you do my head in some times)

I worry that we as developers also suffer a bit of the old confirmation bias though too.. I know I have my own agenda when pushing for a requirement to be included or rejected. And sometimes can be a complete bastard - like the time I was in a room of managers, with the GM wanting his own hobby horse to be looked at. I just did a quick head count and announced "Four people in the room, and only one can make the change you're after. I don't think it's going to happen"..

But seriously, you're absolutely right - but having to ask "what's the real value you're after here?" makes me feel like a tool. I want to encourage people to have a say in how things turn out, but not to get offended when we say "that's nice, but we can't implement what you want in the budget you've put before me".. or "that's really dumb, but you tried hard.. well done".

We have a saying at work.. or rather I have a saying that I say often enough that it'll soak in somehow.. that is: the map is not the territory (see: en.wikipedia.org/.../territory_relation) - by which I mean the problem space described by users, BAs, etc is not the same as the solution space. Indeed, if the problem space - usually a messy, complicated, horrible part of the world - is used to model the solution then you're not really making any headway, other than guaranteeing you'll have a job in 12 months (coz everyone loves maintenance work).

I'll make a vow, right here and now, to thank people for their contribution and for articulating the problem so well - then go and come up with a solution that's at least an order of magnitude less complex than the problem it's trying to solve..

Thanks for the article Casey.. I'm going to take a walking stick into the team meeting tomorrow.. :)

ferrisoxide wrote re: Perceived Requirements or “All Users Lie”
on 03-05-2009 6:06 PM

Hmm.. ok.. that was a bit of a rave.. must learn to write comments after I've actually thought about them (see: http://xkcd.com/481/)

A useful tool for getting to the heart of a requirement is the 5 Whys (en.wikipedia.org/.../5_Whys). Essentially, keep asking 'why' until you're satisfied the requirement actually is related to some core business value and not  some weird quantum virtual requirement created in a clue-free vacuum (hmm.. zero-point requirements).

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)