Less Haste, More Speed

Jeffrey Ventrella in The Case for Slow Programming:

Venture-backed software development here in the San Francisco Bay area is on a fever-pitch fast-track. Money dynamics puts unnatural demands on a process that would be best left to the natural circadian rhythms of design evolution. Fast is not always better. In fact, slower sometimes actually means faster – when all is said and done.

Jeffrey’s right in suggesting that we sometimes need to go slower to go faster, unfortunately he makes the mistake of believing that committing and releasing in very short cycles is the cause of these problems:

My programming style is defined by organic arcs of different sizes and timescales, Each arc starts with exploration, trial and error, hacks, and temporary variables. Basically, a good deal of scaffolding. A picture begins to take shape. Later on, I come back and dot my i’s and cross my t’s. The end of each arc is something like implementation-ready code. (“Cleaning my studio” is a necessary part of finishing the cycle). The development arc of my code contribution is synonymous with the emergence of a strategy, a design scheme, an architecture.

This kind of design and development arc is completely independent of how often the developer commits or how often a release is taken. As you speed up your commit and release cycle, you mostly shouldn’t change the design and development process of any given change you simply reduce the size of the change. By tackling much smaller problems at a time it’s much easier and quicker to go through the full arc of understanding, experimenting, scaffolding, building and tidying.

Part of making each small change is considering how it fits in with and modifies the overall system design. Bad development teams forget this and wind up with an awful mishmash of designs all cobbled together, but that’s a reflection of the team’s design ability, not of the process. Good teams gradually adjust the system design as they go, sometimes in subtle ways sometime with more radical changes. Doing so means the system design is optimal for each stage of its life.

Commenter mmlac nails it:

Maybe [the machine-gun committer] IS doing the same as you, just sharing the progress with the team, so people can spot obvious mistakes earlier and see the approaches and stop him in time if they have more experience with the way they are trying to go?

You are basically advocating waterfall. And the issues you face have nothing to do with the speed of coding and the number of commits.

That’s not to say that there isn’t value in the saying “Go slower to go faster” but the much better way to phrase it is “Less Haste, More Speed”. It’s not about going slow, it’s about not rushing and doing a good job. It means taking the time to break down large changes into smaller, simpler incremental changes so you don’t have to deliver them all in one go. It means considering what adjustments to the overall system design are required for each change to make it fit in well.

And it means committing and releasing more often. Regularly investing time to prove things are completely finished and sent off to users instead of building that time up as technical debt because you’re attempting to make too big a change at once.

You don’t go faster by simply trying to go faster – you go faster by identifying and eliminating bottlenecks which requires you to do things that individually appear to make you go slower but make the overall system go faster. Committing and releasing regularly (continuous integration and continuous deployment respectively) are solutions to the bottle neck of horrendous merge and release processes that result from not doing them regularly enough.