"Just do it"® is a registered trademark of the Nike Corporation, and a phrase that they made famous. But it's common in business to urge a company to have a "bias for action". That means that it's often better to not "over think" a problem, but rather to simply act.

Early in my career at Kronos, Larry Baxter (one of the founders of Kronos) thought about the following scenario. At the time, digital wristwatches were just beginning to displace old-fashioned analog wristwatches in the marketplace (the older ones were usually mechanical, and hand wound). But there was a question as to which technology would be used to produce the digital displays, light emitting diodes ("LEDs"), or liquid crystal displays (LCDs"). ^Note 1 

Larry asked us to consider four hypothetical companies approaching this problem in different ways, summarized in the following chart:

Now, which of these four companies will win out in the marketplace? What Larry Baxter wanted to point out is that it will probably be company C or company D. One of them will have chosen the correct technology, and will also have gone to market quickly, giving them a substantial advantage.

Company A or B will correctly pick the winning technology based on their 1-year study, but by virtue of taking so long to do so, they will enter the market late. They have little chance of winning in the end, because they spent too much time thinking about the problem, and didn't act until too late. Of course, the company that spends a year studying the problem and still picks the "wrong" technology is a loser on both counts.

Note that a selection can be "wrong" for many reasons other than lack of technical excellence. Even a good technology can lose for marketing reasons, mismanagement, or just plain random bad luck. Many people consider that the "Betavision" video cassette system was technically superior to the "VHS" system, but the Beta system lost out in the marketplace for other reasons.

Based partly on Larry Baxter's philosophy, Kronos generally preferred to make decisions with what they called a "bias for action", which one might characterize by the Nike trademark, "Just do it". This was also the preferred mode of operation of another company founder, and longtime company president, Mark Ain. Although he had a background as a marketing consultant, Mark was a master of doing very brief and to-the-point marketing surveys, often rather informal, and then proceeding with product development without spending a lot of time or money on elaborate studies. ^Note 2 

So it's important to not "over think" a problem. Or is it? I spent most of my working career in the software industry, in which writing a computer program is often referred to as "coding". And a famous principal in that industry is, "The sooner you start coding, the longer it will take you to finish." ^Note 3  When creating something complex like a computer program, careful upfront planning has an enormous payback. If you charge in too fast, you usually get into trouble.

This was something I learned, at least on a simple level, very early in my programming career, in a computer programming course, in fact. It was a course in the computer language "LISP", a rather unusual programming language much used at the time in Artificial Intelligence research. The class was given the job of writing a program to solve a particular problem. ^Note 4 

I immediately charged in to writing a program to solve the problem using search methods. But as the program I was writing got more and more complicated, I stepped back and thought about the assigned problem a little more. And the more I thought about it, the simpler and simpler it became. It only took an hour or so of analysis to realize that I could write the LISP computer program in only a few lines.

After all the students in the class had submitted their programs and had debugged them over several computer runs, the instructor revealed his solution. He had thought about the problem a little bit more than I had, and he was a much better LISP programmer. His program accomplished the task in a single line. That was the first time it really hit home to me that a little bit of upfront thought and analysis can go a long way.

Thinking way back to an event at camp Robinson Crusoe, where I was a camper for many years in the fifties, I recalled another example of quick action. We had cut down some trees in order to make light poles for our basketball court. Being mathematically inclined, I was able to use some simple geometry to accurately estimate the height of the trees before cutting them. Having seen many pictures of loggers floating their trees downstream to the sawmill, we rolled the first tree into one of the camp lakes, in order to float it to the other side. It sank to the bottom like a stone. That's when we realized that a tree will only float after it has had some time to dry out.

I don't remember whether we found some trees that had already been cut and dried, or whether we simply came back the following year to the same trees we had cut. But eventually, we were able to float some suitable trees across the lake. We then needed to haul the trees out of the lake, dragging them up along the steeply-sloped beach. They were still too heavy to do this by hand, but of course we had a truck.

"Let's think about this", I said, "It's not a good idea to drive the truck onto the sand." But the counselor with the truck didn't want to discuss it or think about it at all. This was long before Nike ever said "Just do it", but that seemed to be his attitude. He thought I was worrying too much, and he backed the truck down the beach. The truck, of course, not a four-wheel drive vehicle, immediately got hopelessly stuck in the sand.

So the camp called for a tow truck, which arrived shortly from the town of Sturbridge. Now that we had one truck stuck on the sand, I suggested that it would be a bad idea to drive the tow truck onto the sand as well. But the tow truck driver wouldn't listen, either. After all, he had a big, strong tow truck. What could possibly happen to it?

What happened to it, of course, is that it got stuck in the sand as well. As the first tow truck driver hung his head in shame, a second tow truck had to be called, with a driver who had sufficient brains to leave the truck up on the road. He played out enough chain to tow the first tow truck, and then the camp's truck, and finally the logs, up the sloping beach from the lake.

Many years later, I saw a much more damaging instance of this "bias for action" in a tow truck driver (I wonder if tow truck drivers tend to have macho personalities). On Memorial Drive in Cambridge Massachusetts, a driver stepped on the gas pedal instead of the brake, barreled across a grassy strip and through what appeared to be a heavy metal fence, and plunged into the Charles River. The car was actually a convertible, so the driver was not trapped inside. Except he didn't know how to swim, and was left floundering in the water as the car sank beneath him. However, a passing MIT student dove into the river, and became a hero by rescuing the driver.

I came along after all this had happened, but in time to see a tow truck arrive. The driver lowered a chain and hooked it to the bumper of the car, which was only under a few feet of water. He then began lifting the car out of the water, a really bad idea. While tow trucks easily lift one end of a car (if it's the front, containing the engine, it's more than half the car's weight), this truck was attempting to lift 100% of the weight of the car, and not only that, the car was completely waterlogged. As the majority of the car cleared the surface of the river, the tow truck's mast collapsed with a loud bang. Obviously, it's the responsibility of someone like a tow truck driver to know the limits of his equipment. Eventually, a much larger tow truck arrived and successfully pulled the car out of the river.

So, should we have a "bias for action", and avoid "over thinking" problems? Or is it better to thoroughly think things out before taking action? My wife Margie suggests that different approaches may be taken by people with different personalities. It seems to me that the approach taken also depends on the situation. It's reasonable to start to work on a problem by spending at least a little bit of time (just a little bit) considering the meta-question, "How much time is it worthwhile to spend thinking before I start". But people should also keep in mind the "80-20 Rule": you often get 80 percent of the return with the first 20 percent of your effort.
 

Note 1:   It may seem hard to imagine now, with 20/20 hindsight, but when watches with digital displays first started appearing, it wasn't at all clear whether light emitting diodes ("LEDs"), or liquid crystal displays (LCDs") would end up being used. LEDs produced a bright and clear display (always red at the time), but consumed too much power to be left illuminated all the time. Thus, the user had to push a button to read his or her watch.

It would seem therefore that LCDs would be clearly superior, since they use very little power, so the display was "on" at all times, to be read in ambient light (a button could be pressed to illuminate a backlight to read the watch in the dark). However, in the early days of liquid crystal displays, they had low contrast, and operated in only a narrow temperature range.

In the end, what happened was that LCD technology improved, leaving it a clear winner for watches. Looking back, it's hard to remember how bad these displays once were. LCD is now the dominant technology used for flat-screen television displays. A so-called "1080p" high definition television display is an array of 1,920 X 1,080 pixels, each of which comprises three colors, red, green, and blue. That's a total of 1,920 X 1,080 X 3 = 6,220,800 elements. And these "pixels" are not just on or off. Rather, the brightness of each is adjusted at least 60 times per second (minimally twice the frame rate, and often 120 or 240 times per second).   [return to text]

Note 2:   Indeed, Mark's decision making could often be called "impulsive". I'd suggest the possibility of offering a customer a particular product feature, and he'd grab the phone to call the customer! I'd yell, "Whoa! We need to think a bit more first - what will it cost us to develop, what can we charge, and so on."

On the other hand, what sometimes looked like impulsive decision making on his part could be deceptive. See a story about Mark's decision making vs. mine in my blog entry "Personalities".   [return to text]

Note 3:   I first came across this adage in an electronic "signature" from Chris Hines. Trying to track it down, I found a web site that attributes it to Roy Carlson, in More Programming Pearls: Confessions of a Coder. But I'm not really sure where it originated.   [return to text]

Note 4:   The instructor called the problem we were to solve the "waterpot problem". You are given a target amount of water you are to measure out. But your only tools are two ungraduated measuring "pots" each of which holds a known amount of water when full. The only operations you are allowed are filling a pot, emptying a pot, or pouring one pot into another until either one is full or the other is empty (whichever comes first).

For example, suppose you have a 3 liter pot and a 5 liter pot, and you need to measure out 4 liters. You can do that by the following steps:

You now have four liters in the five liter pot, the desired result.

As students, our job was to write a computer program in LISP which accepted three numbers as input: the size of the smaller pot, the size of the larger pot, and the target amount of water to measure out. The program's job was to print a list of steps to achieve the desired result.

The name of the computer language we used, LISP, originally stood for "List Processor" (although some wags suggested that the name actually was an acronym for "Lots of Irritating Single Parentheses"). Actually, as in a sentence, parentheses had to be matched in LISP - each opening parenthesis had to be matched with a closing parenthesis. But the syntax of the language produced lines with many parentheses one after another - often dozens of them.

Back in the days of "batch processing", programs were entered into the computer on decks of Hollerith cards ("IBM cards"), and the decks of programs to be run in sequence were simply stacked on top of each other, and read one after the other. At the end of a LISP program, the following card was always placed at the end of the deck:

This was in case the LISP program preceding this card had one or more un-matched open parentheses. The LISP Interpreter (the program that read in and directed the execution of a LISP program) would then chew into the characters on the STOP card, as someone put it, "trying to satisfy its insatiable appetite for closing parentheses", until all the open parentheses had been matched.   [return to text]