Cutting Without Measuring

We’re having our front steps replaced. They are made of concrete with embedded tiles (the old steps were badly cracked, and had to be removed anyhow when we had our foundation rebuilt). We were able to salvage about half the tiles from the old steps as they were destroyed, and managed to find matching new ones for about $15 a tile. My wife and daughter spent about two hours laying out the tiles on a sheet, marked with tape to the measured size of the steps, and with the location of each tile measured out. The tiles are each marked to indicate which one goes where (they are various different colors). This map will be used by the builders to place the tiles precisely into the concrete before it dries.

The amount of time spent planning for this task of placing tiles far exceeds the amount of time which the task will actually take. This approach is captured in the old carpentry dictum “measure twice, cut once.” While participating in this tile project, I couldn’t help noticing that this is not how programmers work. It is appropriate to take a long time to measure the tile location because once the concrete dries–a couple of hours at most–there is no going back. The tiles will be set into their position, and the only way to change them will be to destroy the steps again.

Programming is quite different. It takes place in a fluid medium. Any decision can be changed at any time. Of course, some decisions are harder to change than others, because they affect more code. But decisions at the level of “change this tile to another color” or “move this tile a few inches” are generally pretty easy to make in code. This fluidity means that programmers almost never measure twice and cut once. In fact, programmers often don’t measure at all. They just code.

There have been various efforts over the years to encourage programmers to spend more time in the design phase before they start the coding phase. I really don’t know any experienced programmer who takes them seriously. Most projects do start with a relatively informal written plan. This plan is helpful but soon becomes inaccurate. It is generally not updated in detail.

This is not inherently a bad thing. It is appropriate for the nature of the medium. Despite the claims made by the proponents of better design, the truth is that the biggest problems in programming do not arise from lack of design. They come where different systems are stitched together, such that the systems were never designed together in the first place. The biggest problems in programming come from managing complexity, dealing with unexpected and unplanned interactions between different parts of the program and between different layers of the overall system.

This complexity is most likely irreducible. Perhaps what we need in our programs is more ability to handle unforseen events. Perhaps we need to write our code so that it does approximately the right thing in all cases, as well as doing the precisely correct thing in well understood cases. Of course the “right thing” to do is an inherently context dependent operation. So this would have to be expressed in the interfaces between components, rather than in the components themselves.

So perhaps what we need is an interface more sophisticated than the function call, one that can describe what the caller expects. So you wouldn’t just say “draw a window this size at this position,” you would also specify what type of data was going into the window and how the window was likely to be used. That information would be used when it turns out to be impossible or inappropriate to fulfill the original request, perhaps because the screen is too small or because the user has requested extra large windows.

Of course, if done in a simplistic manner, this amounts to adding parameters to the function call, which just pushes the problem back one level. Is there any way that we can capture this kind of fuzzy information in a useful way? Can our programs automatically learn what to do in unexpected situations? Can we provide mechanisms that we can use to teach them?