Chapter 1
Program for Production

When you program for fun, it’s easy to skimp on things such as handling edge cases, error reporting, and so forth. It’s a pain. But when you program for production—not to mention a paycheck—you can’t take the shortcuts.

Production-quality code seems like a straightforward goal, but our industry has had a heck of a time figuring out how to get it right. Windows 95, for example, had a bug that would hang the OS after 49.7 days of continuous operation—which wouldn’t be especially surprising except that this bug took four years to discover because other bugs would crash Windows 95 long before 49.7 days could pass.^[1]

You can take one of two approaches to quality: build it in from the beginning, or beat it in afterward. The former approach requires a lot of discipline in your day-to-day coding. The latter requires a lot of testing and, in the end, a lot of work after you thought you were done.

Beat-it-in-afterward is how it’s usually done. It’s implicit in the waterfall development method that dominates industry: specify, design, build, test. Test comes last. The product goes to the test department and blows up quickly. It goes back to engineering, you fix bugs, you give another version to the test department, that blows up in some other way, and so it goes back and forth for many months (even years).

Much of this chapter’s focus is on build-it-in techniques because that’s how you build a product that you can have confidence in, add features to, and maintain for years. Of course, building production-quality software is a topic that spans more than one book, and its scope is much larger than testing. This discussion, however, is limited to things you can do right now to improve the quality of your code:

• Before getting into specific practices, we start with Tip 1, ​Beat Up Your Code​ to get you into the right mind-set.

• Next, in Tip 2, ​Insist on Correctness​, we focus on verifying that your code does what it should.

• You can also go the other way around; in Tip 3, ​Design with Tests​, we look at starting from tests and using those tests to drive your design.

• Very soon you’ll be swimming in a huge code base. Tip 4, ​Tame Complexity​ deals specifically with the sheer mass of production-sized software projects.

• Tip 5, ​Fail Gracefully​ takes us far off the happy path, where your code needs to cope with problems outside its control.

• Just when things get really gnarly, we take a short breather: Tip 6, ​Be Stylish​ helps you keep your code pretty—and that helps more than you’d imagine over the long haul.

• Back to the hard stuff. Tip 7, ​Improve Legacy Code​ deals with code you’ve inherited from your predecessors.

• Finally, in Tip 8, ​Review Code Early and Often​ you’ll work with your team to ensure your code is ready to deploy.