We’ve seen why metaphors can hurt how we approach software. When we take them too far, we develop habits built around false pretenses. Metaphors are a double whammy. Not only do they make us do things less efficiently, but they keep us from thinking about better ways of doing things.

Wireframes and detailed specifications take time away from building and reviewing the real thing. They don’t take advantage of the opportunities we have to constantly iterate. They make us think through the entire process of writing code without actually having written any code yet.

The over-emphasis on launch hides the fact that software today can be modified and redistributed with relative ease. We don’t “ship” software anymore. We download it off the Internet, or the software itself is entirely web-based. When launch dates get pushed back because features absolutely need to be crammed in, developer morale suffers. It’s a complete buzz kill for a development team.

The traditional roles in software development, between architects, developers, and project managers, inhibit those who have talents in multiple areas. You can be a great visionary, a thoughtful programmer, and a clear communicator at the same time. Following the metaphor too closely inhibits really talented people from all the opportunities this industry provides.

One way to circumvent this problem is to find a more appropriate analogy. Software development might be closer to writing a novel or composing music. Consider how these kinds of professionals “plan” their work.

An author might write a chapter outline to get a general guide about what she wants to write about. But after that, she starts writing the real thing. Then she edits and repeats—a word change here or an entire chapter removed there. Writing is a lot more like how we program.

A musician doesn’t write sheet music for months and then hope the notes sound right. He plays and plays and finds a riff that works. He might have a few lines of lyrics and then find the right chords around it, or vice versa. He builds the song in pieces and tests it in pieces.

In both cases, the cost of materials is cheap. Paper and pen are readily available. Guitars don’t get paid by the note because sound is cheap. Just the same, code is our own cheap material. Once we have our development environment set up, there is no material cost of writing code.

So, use our traditional metaphors for development as a stake in the ground, when you’re not quite sure how to approach a software problem or when there’s not enough information to make sound decisions. But once you’ve run with the metaphors for a while, look up. See where they’re still helping and where they might be hurting your process.

With this knowledge in place, we’re now keenly aware of whether the processes we abide by actually work. The next step is about the long-term. How can we keep ourselves motivated throughout the course of our development career? Next, let’s discuss a few ways we can sustain our motivation.