Thursday - February 23, 2006

Rat-holes of Lost Time

Much of software development is best described as
"problem-solving". Much of the rest, BTW, is knowledge
capture.

When we look at the time spent
on problem solving we can see four potential outcomes.

1. Time is spent producing a viable solution to
the actual problem.

2. Time is spent producing a non-solution to the
actual problem.

3. Time is spent producing a solution to
something that isn't the actual problem.

4. Time is spent producing a non-solution to
something that isn't the actual
problem.

Obviously, we want to invest
in the first (solving the problem) and avoid non-solution activity, and
non-problem-focused activity. The latter three situations are sometimes called
"spinning the wheels", but they are very different situations, almost nothing
alike. We'll separate #2 (non-solution) from #3 and #4
(non-problem).

A non-solution is one of
those regrettable situations where the programmers think and work and meet and
develop and when they're done, we have one or more new problems. Sometimes the
new problems are less onerous, which means we are seeing progress. Other times,
the new problems are no less a burden, and we've merely shifted the problem
around a bit. Sometimes, the lessons learned have more value than the
non-solution.

Bad algorithms become a
large and costly processor; bad data structures become a large storage array and
complex backups; non-solutions to the real
problems.

Activity focused on a
non-problem is much more costly. When we're done, we haven't addressed the real
problem at all. We haven't changed the problem to something simpler, we haven't
shifted the problem to something more tractable, nor have we learned lessons
which can be applied to solving the
problem.

We make a wrong assumption, we
code to that assumption. At the end of the day, some (or all) of the code is
worthless. Perhaps, surfacing the bad assumption is a good thing, but we
weren't even addressing the problem, we were working around our faulty
assumption. Couldn't we have spotted the wrong assumption
sooner?

Perceptual
Narrowing. Pursuing non-problems and
non-solutions are two examples of "Perceptual Narrowing". We think that our
activity is important. However, a little reflection reveals that it can't lead
to success. The sooner we can see that we are not going to be successful, the
sooner we get out of the rat-holes and onto a useful course of
action.

The trick in avoiding
perceptual narrowing is to stop doing what isn't working, breathe normally and
think logically about what we need to accomplish, not what we think we need to
do. When should we stop? How do we know to
stop?

Strategies.
Pursuing a non-solution can be prevented by setting more than one mind to the
activity. Exposing your thinking in pairs often separates rat-holes from viable
paths toward a solution. The process of "talking it through" forces some
justification and some focus on the core
problem.

Pursuing a non-problem is
largely prevented by active management engaged in the problem-solving process.
The idea is to assure that the technical giants really understand the problem,
the cost of the problem and the value of solving the actual problem -- as
presented.

The real challenge is to
assure that the problem is defined, and the value of a solution is also defined.
Too many technical people are left to contemplate the myriad, interlocking
mysteries of business, technology, corporate strategy, budget, schedule, and
risk. There are sub-problems, contingent problems, derived problems, nascent
problems and irrelevant details.

Cutting the Gordian
Knot. One technique that can be applied to
sorting out the problem from the non-problem, and the solution from the
non-solution is a multiple-step process. Taking multiple steps is a way to
expose the thinking at the end of each step, providing some reflection, feedback
and chance to articulate where we are and where we are
aimed.

First, and most important, is
defining the problem. IT people leap past the problem into the solution as
naturally as they breathe. It's a hard habit to
break.

Second, and almost as important,
is a written record. A meeting that defines the problem and produces a written
statement of the problem is an excellent start. Once defined, solutions can be
brainstormed at a separate meeting. A written log of ideas, subject to some
review and thought, is a great way to select viable alternatives for further
investment.

On Your
Own. But what do you do when you're solving a
small problem, by yourself, in your cubicle? The same discipline applies. Big
formal documents, of course, are a waste of time. However, a "journal" or
"blog" of problems, alternatives and solutions is just what the doctor
ordered.

Programming -- as I claimed at
the outset -- is knowledge capture. If you can't write, you can't code. You
don't have to write well. But you have to be able to write in a variety of
languages. Svenska, Engelska, Python, Java, SQL, XML, HTML, JSP, are all just
part of the job.

When working alone,
it's critical to write things down. The discipline of writing will often lift
up a non-problem for what it is -- a rat-hole of sunk cost. Other times, the
written summary of the candidate solution is something we'd be embarrassed to
publish; if so, why put in any
time?

Faulty
Assumptions. The discipline of writing may be
the best way to surface improper assumptions. How? The answer is references.
A footnote is what separates a fact from an assumption. Preventing faulty
assumptions may be the way to prevent the perceptual narrowing that leads us
into a rat-hole of lost time.