Solving the right problem

by Pascal Rettig posted Oct 01, 2010

Jeff Atwood, in the fantastic development blog Coding Horror posted a question a while back:

Let's say, hypothetically speaking, you met someone who told you they had two children, and one of them is a girl. What are the odds that person has a boy and a girl?

 In Jeff's mind - as he goes over the next day - the question has a lot to do with probability, and if you factor in the conditional probability that someone has both a boy and a girl given that one of the children is a girl, the answer is 2/3. Or, as one of the commenters from the first post brought up - the answer could be 1.0. After all, who would tell someone 'I have two kids and one is a girl' and not mean that they other one is a boy?

The solution, of course, depends on who's asking the question and what kind of question are they asking. If this was a riddle and not a probability question then the answer would have been different. In this case (while he doesn't explicitly write "this is not a trick question") Most people correctly got the idea that he was looking for a mathematically reasoned response.

The same ambiguity can occur in client-driven development - oftentimes a client comes looking for a specific answer, but there might be two different ways to solve the problem depending on some additional criteria they aren't telling you about. Make sure you are solving the problem the client wants solved and not the one you want to solve.

Oftentimes clients think they are looking for certain features, but the truth of the matter is that they are actually looking for certain results - for example, allowing people to see upcoming events, but they've clouded the results that they are looking for with features that they've seen somewhere else. User Stories need to drive development, not a list of client-written specifications with features.

This is one of the reasons that I like custom development so much then using stock solutions - maybe the best solution to the problem isn't necessarily the one that's out there that the client has already seen. While the functionality or end result might be the same, other factors may dictate a different solution.

Let's take a simple list of events on a website - how should that list be displayed? A standard table format might work if there are only a couple of events, or a fixed size calendar if there's maximum one event per day, but how about maximizing screen real-estate when there are a number of events interspersed throughout the day? A fluid calendar would probably be the way to go but does make the page less structured any makes it more difficult to analyze schedule openings.

The best solution might depend crucially on the size and distribution of data set your client is going to have as well as the amount of processing power you have at your disposal - giving your users the ability to view a set of data from any angle is fine as long as that data set stays small, but once it grows beyond a certain size your database is going to slow to a crawl on any non-indexed search or sorts.

The long and the short of it is - make sure you are answering the question the client is asking, sometimes you need to ask a couple extra questions to get at the appropriate solution, otherwise you'll end up with a absolutely striking, beautifully coded 10,000+ line event system for you client's once-a-year open conference (Which is what we almost ended up building for someone before we asked some additional questions.)