Software development is complex and difficult and unlike most other professions that I know of. This makes it tough to explain to colleagues in other parts of the organization, clients, and (all too often) management. We’ll typically try to find something well understood to use as a basis for comparison. Something to help explain the idiosyncrasies that come along with building software and being a software developer.

Software development is just like manufacturing, right?

I’ve heard dozens of comparisons of software development to other professions or activities. My least favorite – although seemingly most popular – is manufacturing. Sure. In both cases we’re building something based on specifications. That’s pretty much where the similarities begin and end. Manufacturing succeeds when you repetitively build the same thing with as little variation as possible. As a software team, if we build the same thing repeatedly then we’re doing something wrong. Software development is about solving a unique problem.

A different metaphor

Metaphors, by definition, are not perfect. Even so, I’d like to try a different one on for size. Lately I’ve been thinking that software development is not unlike drawing. Hang with me for a second… I’ll explain. Now, I’m not a drawer or a painter or a police sketch artist. But imagine having to draw or paint a scene from the real world. But in this case you have to recreate the scene from someone’s description. This is pretty much what we do every day in software. We bring people’s ideas to life, only we’re doing it on a computer screen rather than a canvas.

Keep playing along – this gets fun

Let’s extend this metaphor a bit to other challenges that we face in the software development world. How many times in your career has a requirement been misunderstood or missed altogether? Gee, I bet that would happen if I were trying to draw your words. Little details, even big details, can easily get lost in translation. “Yes, I said there was a bridge there, but it was iron – not brick.”

Or how about the situation where the user doesn’t exactly know what they want? “Can you paint a yellow-ish, blue-ish but definitely not green-ish house? Oh, now that I see it maybe green is right.” But sometimes your artistic influence leads them in another direction. “I had pictured this as a midday scene, but I love the way you have amber the sunset reflecting off the water. Let’s go with that.”

And now for one of my all time favorite lines of though. This being that we can add more people to the team and deliver software faster. Any software developer knows this is true to a point. But once that point is crossed, adding people will actually slow the team down. Also, the smaller the project and the closer to being “done” the harder it is to have more hands on the code. I’d image this is true when painting, as well. It may very well be possible to have three artists working on the same painting at the same time. The larger the painting, the more individual components, the more ways to split up the work. Can you imagine thirty artists working on the same piece at the same time? I expect this wouldn’t work so well.

But software, like drawing, is soft!

Across the industry there are folks who seem to forget that software is supposed to be “soft”. We’re not welding a steel frame together. We’re typing words into an editor and almost magically creating something that the user can interact with on the screen. Changing direction, even late in a project, is supposed to be easy. When we make it difficult all we’re doing is reinforcing that notion that software development is similar to manufacturing. Do yourself a favor and be nimble in your process and your architecture. There’s no need to redraw the whole city just to change the brick bridge to an iron bridge.