Chapter 7: Discovery

Overview

It is said, A journey of a thousand miles begins with a single step.

”Anonymous

This adage is usually quoted as a motivation: Get started, and the rest will follow. The adage misses the potential problem, however, of what happens if that first step is in the wrong direction. It isn t necessary to be a fan of chaos theory to recognize that even the smallest change in initial conditions (the first step) can have enormous impact on the eventual results.

For instance, suppose you are in Albuquerque, New Mexico. (Bugs Bunny was famous for making a wrong turn here.) You want to go to Washington, D.C., following a direct line slightly north of east. Unfortunately, you were celebrating your coming departure last night, you arose much later than usual, and, thinking it was morning and the sun was rising in the east, you headed off in the direction of the sun. You might still get to Washington, D.C. (the Earth is round, after all), but your journey will be rather tortuous and take an inordinate amount of time.

Beginnings are just as critical in software development, and initial mistakes are a lot more common than one might suppose. A truism of software development is that the most costly mistakes are made the first day. Two major factors make beginnings so perilous in software. The first is simply a lack of knowledge. We know the least about the what, the how, and the why of our development project at the beginning. This should be so obvious that it need not be stated, but surprisingly, we insist on making critical decisions about projects (such as overall design, timelines , and costs) at the very time we are least prepared to make them.

Management usually takes the heat for this mistake. An oft repeated statement (that I heard in a keynote speech at a conference, but is really a paraphrase of a famous Santayana quote ^[1] ) is, Insanity is doing the same thing that failed last time and expecting it to work this time. Management, it is said, is guilty of precisely this and therefore should be considered insane. But it is not insanity at work here ”it is culture. If the rationalist philosophers had been correct and the formalist software engineers had been correct, it would have been perfectly reasonable to assume that we should be able to define perfect specifications and derive working software from those specifications with mechanical transformations. Computer scientists, software engineers, and rationalist western culture in general have been selling management a bill of goods.

The second most common source of error, especially by experienced developers, is to anticipate how the computer is going to implement your software before trying to understand how the software should simulate some part of the domain in which it is going to be used. This is computer thinking , as described in earlier chapters. If you start the development process, as is almost always done, focusing first on what you are going to tell the computer to do  and how it is to do it, you have started your thousand-mile journey with a 180-degree misstep. There may have been a time when computers were so hard to use, limited in capability, and expensive that it was expedient to use them and their requirements as a lens through which the rest of the world was cut and measured, but that is clearly not the case today.

Note  

The argument in favor of computer thinking almost always revolves around the issue of efficiency or performance. But as the developers of SIMULA discovered , if you get the modeling and simulation correct, you get a surprising amount of performance as a byproduct. One of the axioms of XP admonishes making things work and making them right before attempting to make them fast. Even classical software engineers are adamant about the need to save performance issues for the very end of development. But it isn t just performance ”it s the focus on the machine as the ground for understanding the software development project that constitutes the wrong first step.

Sometimes it is necessary to foreshadow implementation (programming). You might need to ask yourself the question, Can I build this? Thinking about implementation can give you a general answer. When you are first thinking about writing tests and code, you will think about how you are going to implement a specific story. You will have already done the design, the identification of objects, visualization of the basic conversations among those objects, and the assignment of methods to those objects involved in your story ”quite possibly in your head or via discussion with your pair programming partner. Thinking about the code at this point provides useful feedback. You might discover you have a bad design, bad language, or code that needs refactoring.

It s never appropriate to tell yourself, This is what the code will look like, so I need an object to hold these parts of the code, and another to hold these parts , and another to make sure these two do what they are told to do when they are told to do it, which is precisely what structured development tempts you to do.

Perhaps the greatest benefit of object thinking is that of helping you start off in the right direction. Object thinking does this by emphasizing the need to understand the domain first .

^[1] Original quote from George Santayana: Fanaticism consists in redoubling your efforts when you have forgotten your aim.