Bad Analogies Suck.

One of the thing I appreciate about working at Atlassian is that everyone is constantly working on self-improvment. In pursuit of this goal, the Team Leads meet once a week to review and discuss a current leading industry monograph (otherwise known as Book Club).

I learned early on in my academic career that books are not meant to be read as narratives, but rather books are an argument. The author is trying to persuade you that his interpretation of events and/or current practices is correct. One of the worst ways to do this is through the use of bad analogies. And yet, bad analogies seem to be one of the predominate modes of writing in IT books. Bad Analogies distract from that argument, or worse, tend to disprove the very point the author is trying to make.

In Agile Estimating and Planning by Mike Cohn, he has a chapter on Buffering Plans for Uncertainty. When planning for a project with a firm deadline and absolute set of functionality, he uses the analogy of getting on a flight. All the steps (driving to airport, passing security) must be completed, and the deadline is set before the project even starts. To ensure the project gets done, he suggests leaving earlier for the airport. The conclusion reached by using that analogy - start your project sooner. In software development, it is usually not very feasible to solve a scheduling problem by going back and starting the project sooner. The normal solution is, of course, to delay release (take the later flight) but the point of his argument was to show how Agile planning can help make that first flight. It is better however than the next analogy I encounter at Book Club.

In Release It!, Michael T. Nygard uses the analogy of a car that fell apart on the test track to show that even when the process works correctly, bad products can result. In other words, he argues that a failed QA effort proves that successful QA doesn't guarantee a good product. Now passing all QA tests doesn't mean the product won't suck, but that point is lost when the example contraindicates the argument.

The irony is that both of these books are really good. They have good insight, and provide practical guidance on how to do agile planning and build robust systems respectively. I just wish they didn't make it so challenging to agree with their arguments.