28   Code in Increments

“Real programmers work for hours and hours straight, without a break, without even looking up. Don’t break your flow to stop and compile: just keep typing!”

When you’re driving on a long trip, does it make sense to hold the wheel firmly in one position, stare straight ahead, and then just floor the gas for a couple of hours? Of course not. You have to steer. You have to be constantly aware of traffic. You have to check your gas gauge. You have to stop for fuel, food, and other necessities, and so on.^[30]

Don’t code for hours, or even minutes, without stopping to make sure you’re on the right path—by testing what you produce. Instead, code in short increments. You’ll find that coding in increments helps you refine and structure the code as you go along. The code is less likely to become complicated or messy; you build the code based on the on-going feedback from writing and testing in increments.

When you write and test incrementally, you tend to create methods that are smaller and classes that are more cohesive. You are not heads-down, blindly writing large pieces of code in one shot. Instead, you are constantly evaluating how the code is shaping up, making many small adjustments rather than a few really, really large ones.

While you are writing code, constantly look for small ways to improve it. You might work on its readability. Perhaps you discover that you can break a method into smaller methods, thus making it more testable. Many of the small improvements you make fall under the general heading of Refactoring (discussed in Martin Fowler’s Refactoring: Improving the Design of Existing Code [FBBO99]). You can use test-first development (see ​Use It Before You Build It​) as a way of enforcing incremental development. The key is to keep doing something small and useful, rather than saving up for a single long session of coding or refactoring.

That’s the agile approach.

Write code in short edit/build/test cycles. It’s better than coding for an extended period of time. You’ll create code that’s clearer, simpler, and easier to maintain.

What It Feels Like

You feel the urge to run a build/test cycle after writing a few lines of code. You don’t want to go too far without getting feedback.

Keeping Your Balance

• If the build and test cycle takes too long, you won’t want to do it often enough. Make sure the tests run quickly.

• Pausing to think and “zoom out” from the code details while the compile and test is running is a good way to stay on track.

• When you take a break, take a real break. Step away from the keyboard.

• Refactor tests as well as code and as frequently.