Metaphors for Programming

In the opening chapter of “The Developer’s Code“, author Ka Wai Cheung describes the book as “a collection of lessons, observations, and missteps I’ve gathered, first-hand, in our industry”.

The following is my summary of Chapter 2: Metaphor. Whilst I’ve tried to do justice to the author’s intentions, the interpretation is my own. I’ve included my comments in italics.

Follow metaphors with care

In other professions (cooking, music) people’s experience tells them if something is good or bad. However, programmers must resort to metaphors like “software architect” because people have little experience with code. Whilst metaphors are useful, they can distort our priorities if relied upon too heavily.

Several examples follow:

Plan enough then build

The architecture model over-emphasises planning over writing code and testing it. Agile development unbinds us from the metaphor.
In construction, the product requires detailed specifications:

  1. re-work is expensive or impossible
  2. task scheduling is complex
  3. raw materials are limited
  4. errors during production are expensive

Whereas in software production:

  1. the construction remains malleable
  2. the product is testable in (near) real situations
  3. errors during production needn’t equate to issues in use
  4. the product can be duplicated at no cost

Launch is just the first release

Buildings are built and then opened. In contrast, software can mature and develop over time, and users are increasingly accustomed to change.
Launch is a milestone, but not the end of a software products life-cycle. Get the important stuff right and fix the small stuff over time.

The “ivory tower” architect is a myth

Real architects don’t hammer in nails, but the division between designing and building software is arbitrary. In reality, software architects need the insights that are only available to coders. Software architects must, therefore, find time to do at least some coding.

Throw away your old code

Unlike real-world materials that are often reused, we don’t need to keep old code because:

  • Unlike real-world materials (bricks, metal and so on) the raw elements of code are inexpensive and easily replaced
  • Commented-out code is distracting
  • We rarely uncomment code that we comment out
  • Resurrecting old code is often more expensive than rewriting it

An important exception to this rule is where you want to keep a record of your thinking rather than the code itself.

Diversification over specialization

Specialised roles in building occur in different physical places, whereas our tasks are all on the same screen. For this reason, there is no reason we can’t be good at a range of jobs.

The logic of this argument is flawed, and the conclusion questionable. While over-specialising can be dangerous, trying to be a jack-of-all-trades can be equally hazardous.

My guess is that this is just a weak example of a powerful idea: the author is trying to illustrate the idea of architecture as a limiting metaphor rather than provide a justification for becoming a generalist.

Metaphors Hide Better Ways of Working

Metaphors both liberate and constrain our thinking.
Where they are a problem:

  1. Learn to see where metaphors are being used and their limitations
  2. Try changing metaphors

Leave a Reply

Your email address will not be published. Required fields are marked *