Tangled in the Threads

Jon Udell, December 15, 1999

Problem-solving Strategies

Why are technical problems hard to solve, and what strategies can help?

Those of us who ply technical trades are engaged, on a daily basis, in the solving of hard problems. Or rather, problems that seem hard until, suddenly, you slap yourself on the forehead, exclaim "Why didn't I think of that before?" -- and get on with your work.

This week, I couldn't stop wondering: Why don't we see these solutions sooner and more clearly? I described one typical experience and put the question to my newsgroup:

Today I helped someone convert a 2-node LAN from an NT/Win95 workgroup to an NT/NT workgroup. Everything went fine, until it was time to replicate the printer-sharing that the Win95 machine had been doing. After conversion to NT, the first NT box (machine A), which had been sharing the Win95 box's printer, couldn't access the NT print server (on machine B).

Eventually I figured out that the problem was something like this:

Finally I realized that by mounting a drive from A to B, the NET USE command in this context could do what a NET USE in a print-sharing context apparently could not: namely, log A into B using a common username but with B's password. Once this drive-mounting operation was done, the print-sharing operation fell into place.

Now, none of these details matters (unless I run into this same situation another time, in which case I hope I'll remember posting this message). Neither does it matter that the OSs were NT and Win95. It's the general nature of problem-solving that this incident has prompted me to think about. It didn't take an inordinate amount of time to figure this one out, but it took longer than I'd like.

So my question is, whether the context is NT or Linux or some other kind of system administration, or whether it is perhaps a programming snag, or any other kind of technical glitch that needs to be debugged: how can you train yourself to focus on the right paths to the solution, and get there as quickly as possible?

I'm sure all of us have spent more hours than we care to think about going down dead-end paths, before finally stumbling on solutions. What kinds of strategies have you found helpful in pruning the solution space so that you minimize the dead ends? Of course, we all get good at solving problems that we've solved before. But what about problems we haven't seen before. In this case, for example, although I've used NT a lot over the years, it's always been in a domain context, never a workgroup context. I've never been confronted with pure NT workgroup, as opposed to an NT domain, so the behaviors I encountered were different from what I was used to. Adjusting to those differences is what slowed me down.

I'm asking: what strategies are effective in novel, as opposed to routine, problem-solving situations?

Dave Caplinger:

I'm sure there is no single correct method, but generally I try to follow this procedure:

  • Go with your gut first. Based on prior experience you probably have an idea of what it might be. Try the first one or two "hunches" but if they don't pan out:

  • Start with the basics and methodically work out from there. There are probably several layers of things that have to work before the one thing you're having a problem with can work. Start at the bottom (is it in fact plugged in) and slowly work your way up (can the machines ping each other) until it breaks. At the end of that at least you've verified all of the "obvious" stuff and you won't now waste a lot of time second-guessing yourself.

That's certainly sound advice. Lord knows, I've followed this procedure myself countless times -- and I'm tired of it! I wish I could figure out how to short-circuit it more often!

In real life, you never have to stop to consider whether, for example, the failure of gravity to operate as expected is a possible explanation for some problem. But the realm of computers and software, you're dealing with abstractions layered on abstractions, and in order to make progress on the higher-level ones you have to believe in the lower-level ones. But in order to debug things, you have to question all assumptions, at every level, all the time. This is, pyschologically, just plain hard.

Video surveillance and the talking cure

Michael Strasser points out that disciplined record-keeping is a key strategy. He reports that one acquaintance literally videotaped all his work, so he could record every step that he took. If you're not willing to live on camera, then he asks:

Where do you document your work so you can recall later how you did it? Some kind of text-searchable database?

Then of course, there's the talking cure, as recommended by Randy Switt:

A great way to clarify things is to try to explain the problem clearly to someone else. I can't tell you how many times I've called tech support, gotten halfway through my explanation of the problem, and suddenly realized what was wrong. Usually the tech doesn't even have the slightest idea of what I'm talking about, it's just that in trying to explain the problem clearly, the solution becomes obvious. Newsgroups are a good place to do this as well.

Andrew Russell points out that the talking cure is useful because it forces you to adopt alternate perspectives. This is what makes collaborative code review -- e.g., structured walkthroughs -- such a valuable exercise.

Of course on a day-by-day, hour-by-hour basis, you can't always recruit colleagues and associates to help solve problems. They're busy solving their own problems!

So how can you become a better, faster, more self-sufficient problem solver? AI software solves problems by iterating the generate-and-test algorithm. That is, it generates branches in solution space, then tests them. Machines can brute-force this process, but people can't. The supposedly-unique virtue of human intelligence is the ability to generate the right smaller solution space.

Nature vs nurture

To what extent is problem-solving a skill that can improve with practice, and to what extent is it just a fixed innate ability?

Peter Hess:

I suspect that problem solving ability is partly inborn and partly learned. Some people are just able to make wild intuitive leaps that turn out to be correct more often than not. Others need to take a more mundane approach. Practice can help, but it will help some people a lot more than others. I can play chess, but I will never be able to play at the level of Gary Kasparov, no matter how much I practice. I'm not wired that way. Isn't that the way it is with everything?

There used to be a ditty on Sesame Street that went: "One of these things is not like the other." It was about figure/ground relationships, and the notion that against a constant background, some foreground detail has changed.

I wonder how much of what we call intuition is really just pattern recognition -- a way of isolating the relevant variables in a situation without being influenced by conditions that tend to obscure what those variables are.

Gavin Brelstaff:

Vision scientists recognize a division (somewhat fuzzy) between perception and cognition. Perception is rapid and can tap many parallel data input channels. Cognition is when you have to think about it to solve the problem.

Research is showing that at least visually we are hardwired to tap parallel real-time channels and to notice certain coincidences between them. Some things we are searching for just pop out because we are built to see them. Others just don't.

Maybe similar idiosyncrasies occur at the cognitive level and Jon is being bugged by the fact that we can't willfully do much to make things pop out!

Maybe that's what's behind the "write it down" or "talk it out" strategies -- they're ways of creating the multiple channels of input that the parallel engine needs in order to work efficiently on a problem. Versus just thinking about it, which happens in a more serialized way.

Maybe that's why many people like to assemble words and pictures related to a problem into some kind of two-dimensional map, or decision chart, or tree, or whatever. This suggests that "thinking visually" doesn't really mean "thinking graphically," but rather, forcing the representation of the problem space onto a 2D plane that corresponds to the visual field, and thus tapping into the brain's parallel-processing horsepower.

This might explain a lot of things! Anyway, thanks to everyone for contributing their insights. Here's hoping that one or another of them will help reduce -- even if just by a little -- the mean elapsed time between head-scratching and forehead-slapping!

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates.

Creative Commons License
This work is licensed under a Creative Commons License.