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.
- Time is spent producing a viable solution to the actual problem.
- Time is spent producing a non-solution to the actual problem.
- Time is spent producing a solution to something that isn't the actual problem.
- 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.