Wait Reviewed

I’ve been reading Wait: The Art and Science of Delay it’s been giving me some food for thought about the strange world of software development. Basically, the thesis of the book is that there is a correct amount of delay between the action and the response to the action. The time scale is kind of irrelevant, whether it’s the milliseconds between someone serving a tennis ball and returning the serve, or the days between making a mistake and apologizing.

It made me think of a comment about my debugging style from a former coworker. He said that I tend to stare at the screen for a long time, then type a line of code and presto, it works. I realized from reading Wait, that what I do is delay and take in all the information possible to come up with the simplest thing that I think can work.

Wait is a book about meta-cognition, it doesn’t really deal with software development. It won’t help you write better code, per se. The main idea in Wait, delaying the response to an action to gather information has direct application to the most difficult parts of software development: gathering requirements.

The requirements gathering process is almost the poster child for the thesis in Wait. If you go off immediately and start creating something you risk losing important information. However, if you delay and continually analyze, nothing ever gets done either. Trying to find that balance of analysis is area in which we have big trouble as an industry.

More to the point is the role of real time prototyping in fostering the discussion. Creating a prototype for people to work with is an excellent way to further the discussion and dig into the use cases quickly. Basically, a prototype gets people to look at an application and thinnk about really using it. By focusing people’s thinking about a concrete prototype, people start to think of it as the way the product will work.

When introduced to early in the process, a real time prototype can have the opposite effect. By getting people to buy into a vision of what it will look and act like, you can stifle creativity and get everyone solving the wrong problem. Because it’s human nature to think of it as an real thing, people get invested in using it, and abandon different approaches.

Conversely, if you wait too long to introduce a prototype, it becomes a hindrance. Because people all have different ideas of how it would look and act, they will all be upset when the prototype doesn’t meet their preconceived expectations. So the right amount of delay is important.

Unfortunately, there is not a specific formula for gauging the right amount of delay. It’s subjective and depends on the situation. The book provides some thoughts about this, but there isn’t really anything more concrete than a rough guideline.