The Timing

Probably the single most important aspect of design is the sequence of events in the software-construction process. Since the earliest days of software development, the sequence of events has been program, bug test, tweak. First, the programmer writes the program. He then puts it through its paces, looking for any inadvertent errors in its construction. Next, he tweaks the code to correct those errors. Finally, the program is ready to be deployed.

It is only natural that the engineers will accept any new discipline more readily if it does not disturb the established order of activities. One method, called user testing, that has grown to significant proportions in the industry examines empirically how actual users interact with the product. The main reason why empirical user testing has been widely accepted in the high-tech business is that it fits easily into the existing sequence. Most user testing depends on having a working program to test with, so necessarily it must wait until the program is up and running. This places user testing in the sequence conveniently in parallel to bug testing. The programmers are comfortable with this piggybacking of a new form of testing because it doesn't upset their established sequence.

As I've pointed out, writing code is to interaction design as pouring concrete is to building architecture. No matter who does the designing, regardless of the method she might apply, the effect of design will be negligible if the coding is underway. A fundamental premise of bringing design to the software-development process is that it must occur before the programming begins. Obviously, I'm an advocate for Goal-Directed design, but any systematic design process performed in advance of programming will be much more effective than any process that comes afterward.

Putting design before programming means fundamental change in the software-development process. Programmers, who are naturally affected by this, see it in vaguely threatening terms. They have heretofore been first and, by implication, most important. If some other discipline comes first, does that mean the other practitioners are more important? This is not true, and I will discuss it in more detail in the next chapter.

In the software world, I have programmed, invented, tested, documented, designed, sold, shipped, and supported, and I can say without doubt that programming is by far the most difficult and demanding task of them all. (I'm referring to professional programming of software suitable for commercial release. As a general rule, the complexity of a program increases exponentially relative to its size in lines of code. Although most people write small, 100-line programs in college, and many people write similar-sized programs for their work, the sheer size of commercial applications, which can easily exceed 50,000 lines, pushes their complexity beyond the comprehension of most mortals.) Even if other practices are unclear on this point, the programmers are not, and they know that they, by far, have more skin in the game than anyone else.

The myth of the unpredictable market that I presented in Chapter 3, "Wasting Money," is another reason why the "program, test, tweak" sequence is so well established in the industry. If we can't know what the market will want, why bother wasting time designing up front? Just code it and ship it, and the market will tell us. It will also absolve us from any responsibility for the failure.

These issues notwithstanding, it is absolutely vital that cooler heads implement this change in sequence, putting design in front of programming.