What Flat Tires Can Teach You About Your Build Process

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_flat_tires_can_teach_you_about_your_build_process.htm]

While driving with my wife this weekend, we started hearing a strange bumping sound in our car. We didn't want to stop because it was the start of a Chicago winter, we were already late to our destination, and our 16-month old son was in the car. However, we quickly pulled over anyway - just as we started smelling burning rubber. Sure enough, we had a flat tire. After demonstrating my amazing car skills and impressing my wife (that's sarcasm - I have no car skills), we got the tire changed. We then drove back home and everything was okay.

Back in the comfort of our warm home, I started thinking how a flat tire reminded me of a broken build:

• Both are dangerous if ignored: You will ruin your entire wheel and eventually car frame if you keep driving with a flat tire. Likewise, you will cripple your application with so many compile and test errors if you keep checking in code despite the build already being broken.
• Both give you clear warning signs: A car with a flat makes an obvious sound, thumping feeling, and smells of burning rubber. A broken build (if you have a continuous integration system like Cruise Control) gives you clear emails about the exact build failure.
• Both don't get fixed by ignoring the problem: A car tire doesn't magically get un-flat. A broken build doesn't magically get fixed.
• Both require stopping what you're doing to fix the problem: In development, I constantly hear "but we're to busy to ". Just like fixing a flat requires you to stop the car (even if you're already late), fixing the build requires at least one developer to stop their features and check in a fix.
• Both can be fixed with relatively little effort: A high-school kid can change a flat time in 10 minutes (i.e. it's not expensive or rocket science). Likewise, if you have continuous integration (and hence can see the exact code-checkin that broke the build, and the exact error that went wrong), it's usually very obvious and quick to make a fix - definitely much easier than if you wait and let the build errors grow.