Next time you refer to software development as “building” something, there’s a good chance that you’re doing damage to your project.
The construction metaphor is widespread in software and IT, and there are several reasons why:
- It sounds like you are creating a thing which can be assessed on its’ own in absolute terms - detached from the social reality of its’ inhabitants or users.
- It sounds like you are doing something, which will eventually be finished.
- It makes software engineers and architects seem more like “real” engineers and architects. All of this sounds very serious and reassuring to clients.
But the worst threat to problem solving is misunderstanding the nature of the problem. And software is nothing like buildings!
- Software is social. Content and data is created by people. Business rules are described and used by people and reflect (and change with) the organization in which they are embedded.
- Software is never finished. There’s always a next version, a “phase two”, a redesign, etc. somewhere on the horizon. And if you’re lucky enough to work on agile projects, this flow of re-alignments is even more accelerated.
- Job titles in the software industry sometimes seem like they’re meant solely to describe our work in terms our grandmothers can understand. In reality, the titles don’t say much about the nature of the jobs.
Today I stumbled on this great collection of some of the many, many software development laws. The author of the post notes that: “some of the laws come from the world of biology — they also appear in some lists of software laws, and I think they still apply.” This observation brilliantly emphasizes why the gardening metaphor (suggested by Andrew Hunt and David Thomas ) suits the art of software development much better than the construction metaphor.
Gardening is about thinking ahead, planning, then waiting patiently and reacting to the ways of nature, nursing, killing bugs and weeds - and season after season learning from your experience.
Good software is created in the same way: Pre-planning using as many skills as possible, then trying out concepts and ideas in real life, nursing and improving what works and getting rid of what doesn’t - then going back and doing it again and again. Good programmers - like good gardeners - know when to immerse themselves in little things and when to take a step back and assess the grand perspective. They understand the intimate connection between the singular detail and the ecosystem.
We already talk about “growing businesses”, so the concept of growing software shouldn’t be hard to explain to clients or investors.
Btw.: As with any interesting topic, Jeff Atwood has written a quality piece about this over at codinghorror.com.