Editorial note: I originally wrote this post for the SmartBear blog. Check out the original here, at their site. While you’re there, take a look around at their offering.
Physical labor is one of the most strangely enduring mental models for knowledge work. Directors and managers of software development the world over reactively employ it when nudged out of their comfort zones, for instance. “What do you mean ‘pair programming’ — we’ll get half of the work done for the same payout in salary!” And that’d be a reasonable argument if the value of software were measured in “characters typed per minute.”
Most of the skepticism of activities like unit testing and code review originates from this same “knowledge work as labor” confusion. The core value of software resides in the verbatim contents of the source code files, so stuffing all of the features in them ahead of the deadline is critical. Testing and reviewing are “nice-to-haves”, time and budget permitting.
The classic response from people arguing for these practices is thus one of worth. It goes something like this: “sure, you can cut those activities, but your quality will dip and there will be more escaped defects.” In other words, these ‘extra’ activities pay for themselves by making your outfit look less amateurish. That argument often works, but not always. Some decision-makers, backs truly to the wall, say “I don’t care about quality — my job depends on shipping on June 19th, and we’re GOING to ship on June 19th, whether it’s a finished product or whether it’s a bag of broken kazoos and cyanide with a bow on it.”
I’d like to take a different tack today and fight a time argument with time arguments. Instead of “sure, code reviews take extra time but they’re worth it,” I’d like to explore ways that they actually save time. Whether they save more time than take is going to vary widely by situation, so please don’t mistake my intent; I’m not looking to argue that they’ll save you net time, but rather that they are not exclusively an investment of time.