Understand the problem

I’m kind of annoyed with myself right now.

I spent the past two days trying to come up with a solution … when I didn’t really understand the problem I was trying to solve.

Now that I understand the problem … I realize that the solution I was creating (which was deceptively simple) was completely off in left field.

This is all related to a some major new functionality we’re building.  This new functionality would negate a technique that some of our customers are using (I’m not going to get into the gory details).

The problem I’m trying to solve is how to support the customers using the specific technique.

The root of this stems from the fact that we don’t have the the special technique documented as a way to solve the customers problem.  The details are mainly what people remember.

As I worked on the problem, at least the problem that I thought I was working on, I realized that it really wasn’t a big problem at all … and the technique our customers were using was not really necessary.

So I talked about it to a few co-workers … and finally realized that, because the problem wasn’t appropriately documented, I had been chasing an approach that was pretty much meaningless.

Your takeaway from this: Make sure you understand the problem you are trying to solve BEFORE you start actually trying to solve it.

Comments

  1. “…More seriously, even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification…”

    — Fred Brooks, from ‘The Mythical Man-Month’

Leave a Reply

Your email address will not be published. Required fields are marked *