This raises a question about the order of events in design. Design is a path-dependent process. That means the early moves constrain the later moves. Think about the cycle. On the very first iteration the design possibilities are wide open. The designer defines some screens and workflows and then the programmer builds those. On the next iteration, it’s not wide open anymore. The new design has to fit into the existing design, and the new code needs to fit into the existing code. Old code can be changed, but you don’t want to scrap everything. There is a pressure to keep moving with what is already there.

Our early design decisions are like bets whose outcome we will have to live with iteration after iteration. Since that’s the case, there is a strong incentive to be sure about our early bets. In other words, we want to reduce uncertainty on the first iterations.

Uncertainty and scope are the same thing. The more scope, the more uncertainty and vice versa. So a good strategy is to reduce your scope on the first iteration so your design/build cycle is centered on a very well understood problem. Build one little feature and nail it. Then build the next one, so your path-dependent process is always moving forward from a state you are proud of.

The alternative is to make many decisions at once, with higher uncertainty, and all those so-so decisions are multiplying as they constrain future decisions. You can never really catch up.

Every feature can be better. It doesn’t have to be perfect the first time. But each element should be solid and well thought-out before you move on to the next.