Find Your Metaphor for Agile Software Design

My friend Richard is one of the most brilliant software developers I have ever known. He really gets object-oriented programming—not surprisingly, because he is one of its original developers.

I often ask my developer friends if they have any metaphors for software development. When I asked Richard, who was an agile practitioner long before the term “agile” was coined, he gave me an answer I wasn’t expecting: “To me,” he said, “software development is like gardening.”

“Gardening?” I asked.

“Yes,” he said. “Working on a codebase is like working in a garden: Every day I am doing a variety of activities. Sometimes I’m planting seeds or tilling the soil, and other times I’m removing weeds or bugs, and other times I’m harvesting. And I’m doing all these things every day.”

I recently asked Richard if he had updated his metaphor response, and he told me that he had.

“If you notice,” he said, “there are joints.”

He told me a story about the chefs in the palace of the emperor of China a long time ago. The master chef was known for never having to sharpen his knife. One day one of the apprentice chefs came to him and said, “Master, we are always sharpening our knives and you never have to. Why?”

“Ah,” the master said, “if you notice, there are joints. Let’s say you want to cut into a leg of lamb. You could try to hack through the bone, but if you move your blade over an inch, you will notice a joint that your blade can slide through without much effort.”

What Richard was saying to me is that the world naturally segments itself, and any problem has natural boundaries within itself. If you pay attention to that natural segmentation, then you are more likely to come up with a design that’s more resilient to change because it will be more likely that the change will occur along a boundary that is already in your model.

I have a lot to say about design. I think it’s a very important area, and there are definitely techniques to help improve designs and make software better.

I’ve accumulated a lot of wisdom about good design by studying other people and what they do. But if I had to give just one piece of advice about doing good design, then it would be just that: Make your model as close as possible to whatever it is you are modeling. Put the joints in the right places and you’ll create a design that’s more understandable, because it is consistent, and that’s more extendable, because very often the changes that are needed can be accommodated by the existing design.

So, what are your metaphors for doing design? Is it solving a puzzle or figuring out the solution to a problem? Is it building models or creating castles in the sky? What is it that draws you to being a software developer? Is it that you want to create something of value to people when they use it, or is it that you want to build something that no one has ever built before?

How you think about design can have a big impact on how effective you are when you do it. I love doing design. To me, design is at the core of a good system.

Different developers have different aspects of development that they like more than others. Software development is such a diverse field that it really requires a range of skills. For example, the skills it takes to be a good software designer are very different from the skills it takes to be a good debugger. However, we do need to have both skills to build software. The good news is that there are people who prefer every option out there.

All of us have different criteria for success, and some of them aren’t even conscious. We have to figure out what resonates for us so that we make the right choices. We can get a clue about the right choices for us by looking at the metaphors we use and by finding ways to improve or create empowering alternatives for the metaphors we use.

And this is not so unlike what we have to do when we solve problems in software development. We are constantly creating metaphors for the processes we are building. We may not even have names for them, but we recognize them when we see them in code. These are idioms that we’ve come to recognize in the pieces we’ve worked on. I think a lot of us have this experience, but we haven’t had much of a forum to share what we’ve done in software, so it feels as if we’re constantly reinventing the wheel.

I see thousands of developers, and I know that each of them has their own metaphors and ways of looking at problems and addressing them. While I know we share a lot of commonality there, we also have a lot of differences, because there are aspects of our work that we haven’t had the opportunity to question and evaluate what really works for us and what doesn’t.

This is why it is so valuable to take time to step back and think about the effectiveness of the metaphors we use. Our field is constantly changing. The best practices of today are quickly superseded, so we must constantly reevaluate how we do our work.

And because our field has many brilliant masters, there are things we can do to immediately and significantly increase our productivity and value as developers.