Seth's Picture

Ask the Right Question

Mon 04 February 2013
By Seth

How fast does this need to be?

Have you ever asked a client (possibly your boss) how fast some feature of the software you're building needs to be? The answer is "as fast as possible". That used to frustrate me because it seemed evasive but now I realize that it's actually not a bad answer. The problem is the question which is focused solely on the software itself

Consider a civil engineer who asked his client how strong the components of a bridge should be. That sounds absurd: it's the job of the engineer to figure that out. The customer would have to say "as strong as possible" or maybe "as strong as they need to be".

One of the differences between software development and civil engineering is that it's obvious to everybody that different materials have different characteristics and different costs but the structure of software isn't readily visible to it's users. That means it's even more important to avoid questions that turn inward on the components of the software itself.

Shift the focus

Let's say you're writing software for a company that manufactures doors. Part of the that software probably involves creating a work order: basically a list of things that the shop needs to build.

Here's a business-focused question you might ask: "How soon can the shop typically start using the information in a work order once they've received it?" If the answer is 4 hours and you're fussing over a few seconds in the button that submits a work order then you're doing something wrong (in this case making the user wait when you could just put their request in a queue and let them continue working).

I think most developers learn not to ask the "how fast" question pretty quickly but it's still very easy to fall into the trap of focusing on the software instead of the what the software does. Avoiding that trap takes a conscious effort and avoiding software focused questions is a good rule of thumb.

comments powered by Disqus