Tuesday, July 19, 2005 

Needs Vs. Demands

Leaving for Udine today, I was waiting for my train. A barely understandable voice announced that the train for Venice would shortly arrive on platform 3. A woman asked me if they had just announced the train from Venice. I replied "No, it's the train from Albenga to Venice". She asked again. I added more details: "Yes, it's the train from Albenga to Milan and then Venice". She mumbled something to herself. I had other things to think about, so I didn't ask the obvious question, "where are you headed to". They repeated the announcement, so she got the name of the first stop (Genoa). "See, it's the train to Genoa". "Yes, it's from Albenga to Genoa, Milan, Venice". "I'll stop in Genoa".
Of course, she could have asked that from the very beginning: "is this train for Genoa?". After all, that was her real problem. Instead, she somehow assumed that the train for Genoa was also from Venice (not to Venice) and she started asking from there. She had a (wrong) solution in her mind, and that was her starting point for her questions. She won't start by telling her real problem. Sure, given a little more motivation :-)), I could have asked the right question and given the right answer. After all, the problem domain was trivial and well known - people want to go somewhere, they don't usually want to take a train from somewhere.
This is not always the case for software applications: the domain can be arbitrarily complicated and largely unknown. Still, the users will keep asking to solve what they believe is their real problem - only to find out that what they asked for isn't really that useful. It is our duty to understand the real problem and design a reasonable solution within the possibilities of current technology. That's why I'm highly skeptical about approaches strongly based on user's stories - they tend to replicate [possibly outdated] solutions, not to make real progress.
For a slightly related paper, see my When past solutions cause future problems, published a few years ago in IEEE Software. Food for thought: if you've ever heard the expression "IT productivity paradox", how many relationships can you find with the above? :-))