Five Favorite Software Development Analogies

I find myself using analogies (or the closely related similes and metaphors [1]) to illustrate points I am trying to make in various facets of software development, especially when talking with someone new to or less familiar with software development. These tend to be specific analogies rather than general software development analogies discussed in posts such as Software Development Analogies [2], Software Development Analogies [3], Using Analogies in Software Development [4], and Writing Software is Like ... Writing [5]. The just-listed posts cover analogies that are intended to describe the overall software development process. The analogies I look at in this post tend to describe narrower and specific portions of software development rather than describing the overall effort. As such, these analogies can even be useful to experienced developers.

Strong Coupling and Dependencies and the Slice of Pizza

When trying to explain how undesirable coupling can lead to dependencies that are difficult to break, I like to use the image of trying to take a slice of pizza and having the desired slice drag the cheese and other toppings of surrounding slices with it. The more tightly coupled the interdependent pieces of the code, the more difficult it is to extract a single slice of pizza (a method, or class, or other code construct) from the greater pizza (greater code module) without dragging parts of the greater along with it.

Brittle Software and the Game of Jenga

The game Jenga [6] involves removing wood blocks from a structure and placing the removed blocks higher up on the structure until someone's misstep (either on removing a block or on placing it precariously on top of the destabilizing structure) leads to it crashing down. This to me is the perfect analogy for brittle software. I use the term "brittle software" in this context to mean software that developers are loathe to change for fear of breaking it or making it worse. This might be software that has thought-to-be-dead code that no one dares remove or code that desperately needs refactoring but involves too much risk to be refactored.

Although a good set of unit tests and regression tests can help reduce risk and fear of changing such code, it is always nice to see clean, understandable, maintainable code that developers dare change with confidence. The interesting thing is that many software projects seem to go through the Jenga game lifecycle. Changes are easy at first in both cases but become increasingly difficult and risky as the game or project goes on and the structure (Jenga tower or project code base) becomes unwieldy.

Concurrent or Not: Nine Women Making a Baby in One Month

Fred Brooks wrote in The Mythical Man-Month [7] the well-known quotation [8] that "The bearing of a child takes nine months, no matter how many women are assigned." I like this analogy for describing the same situation that Brooks uses it for: to point out that not everything can be done concurrently (in code or in assignments) and that some things must be done sequentially. However, I also like the analogy as a way to explain the basics of concurrency versus no concurrency.

Ignoring Warnings: Sweeping Dirt Under the Rug or Hiding Junk in the Closet

I like the analogies of sweeping dirt under the rug or hiding junk in the closet to explain why it's not a good idea to suppress warnings rather than fixing underlying code and why it's similarly not a good idea to ignore compiler warnings [9] or IDE hints [10]/inspections [11]. Although sweeping dirt under the rug or stashing a pile of junk in the closet may make things appear superficially cleaner, the dirt and junk are still there and are still going to cause an eventual problem. Hiding them doesn't fix the real issue and is only a temporary workaround.

Comments are Deodorant for Stinky Code

I first heard the quote [12] "Comments are deodorant for stinky code" (or "code smells [13]") in Kevlin Henney [14]'s presentation Programmer's Dozen [15]: Thirteen Recommendations for Refactoring, Repairing, and Regaining Control of Your Code [16] at SDWest 200 and have liked the metaphor ever since. I do think some comments have value (such as Javadoc methods describing pre-conditions and post-conditions and other contract details), but in-method comments often do seem to be extraneous or redundant at best, downright misleading or out-of-date in other cases, or must exist because the code they describe is inscrutable without them. It is this last type of comment (the type of comments needed to make confusing or nearly impossible-to-read code understandable) for which this metaphor works best.

Conclusion

I have used this post to describe five of my favorite analogies for explaining particular aspects of software development: too high couple illustrated by pizza slice taking the rest of the pizza with it, Jenga game representing brittle software, nine women having a baby in a month representing ability or inability to run certain tasks concurrently, sweeping dirt under the rug or hiding junk in the closet representing ignoring of warnings and hints, and comments (sometimes) being used as the deodorant for stinky code (code smells).

Original posting available at http://marxsoftware.blogspot.com/ [17] (Inspired by Actual Events)