Jeff Atwood at Coding Horror wrote a post yesterday about software development metaphors, and it was pretty interesting, especially his citation from McConnell's Code Complete 2:
However, I think the list of metaphors above is a bit muddled, because development is actually two kinds of activity, individual and group. Some of the metaphors seem to apply more to one person doing the work, others to the process as a whole. Some thoughts....
For the case of an individual working on software, I've always found the work to be something of a craft. By that I mean the intersection of art and science, both combining to create something of value. It's really not an art; much of the effort is not inherently creative, and it doesn't generally have the self-directed nature of great art. It isn't a science either, in that the vast majority of code writing is not the result of a repeatable, verifiable process.
But development is akin to a craft, say cabinetmaking. One uses the results of science (a computer language and tools in one case, stain and tools in another), but neither person is actually doing anything new. It's similar to art, assuming you're trying to create something of beauty (and most developers are, believe it or not - for my definition of developer, as opposed to programmer and engineer, see my post of June 2), but it fails for the reasons above.
There is, and should be, a pride in that; I always have found it, but I have never tried to convince myself that I am an artist. If we believe that, we are forced to include all sorts of things as art that really aren't, simply because they have a kind of beauty. An organized desk can fall within that definition, and that's stretching the concept of art beyond proportion.
Programming more closely resembles science, but I think it still falls short. Perhaps one can make a case for some design activities as scientific, but the actual development is rarely so. I may have a more pure definition of science than others, though.
Development is also a group activity, and, there, others of the listed metaphors seem to apply. Yet none of them seem quite right, either. I imagine that this is because group development is inherently complex, and the more singular something is, the less likely we are to find a suitable or useful metaphor for it. It's possible that development is sui generis, that it is similar only to itself.
It's also possible that no single metaphor can be found because every project is different. I've worked on projects with strong methodologies, and they did come close to being like a manufacturing process. I've worked on others which were virtual chaos, in which no rational person could find enough consistency to create a metaphor.
In the end, I guess I'm not sure why people try to create these types of metaphors, other than we seem to have a natural tendency to do so. I don't think I need a metaphor to understand what, say, a firefighter does; if I'm motivated, I'll learn about the job itself - no metaphor needed. The same is true of software development...if you have to ask, you'll never know (to paraphrase the great Louis Armstrong). In fact, these thoughts have fatigued me; I think I'll go put on some Hot Five.
A confusing abundance of metaphors has grown up around software development. David Gries says writing software is a science (1981). Donald Knuth says it's an art (1998). Watts Humphrey says it's a process (1989). P. J. Plauger and Kent Beck say it's like driving a car, although they draw nearly opposite conclusions (Plauger 1993, Beck 2000). Alistair Cockburn says it's a game (2002). Eric Raymond says it's like a bazaar (2000). Andy Hunt and Dave Thomas say it's like gardening. Paul Heckel says it's like filming Snow White and the Seven Dwarfs (1994). Fred Brooks says that it's like farming, hunting werewolves, or drowning with dinosaurs in a tar pit (1995). Which are the best metaphors?Atwood concludes that the best metaphor is "whichever metaphor helps you and your team get to the end of the project (emphasis his)." The one he favors is the Hunt-Thomas analogy to gardening, and it is clear that farming is especially resonant with him, and I suggest you read his ideas.
However, I think the list of metaphors above is a bit muddled, because development is actually two kinds of activity, individual and group. Some of the metaphors seem to apply more to one person doing the work, others to the process as a whole. Some thoughts....
For the case of an individual working on software, I've always found the work to be something of a craft. By that I mean the intersection of art and science, both combining to create something of value. It's really not an art; much of the effort is not inherently creative, and it doesn't generally have the self-directed nature of great art. It isn't a science either, in that the vast majority of code writing is not the result of a repeatable, verifiable process.
But development is akin to a craft, say cabinetmaking. One uses the results of science (a computer language and tools in one case, stain and tools in another), but neither person is actually doing anything new. It's similar to art, assuming you're trying to create something of beauty (and most developers are, believe it or not - for my definition of developer, as opposed to programmer and engineer, see my post of June 2), but it fails for the reasons above.
There is, and should be, a pride in that; I always have found it, but I have never tried to convince myself that I am an artist. If we believe that, we are forced to include all sorts of things as art that really aren't, simply because they have a kind of beauty. An organized desk can fall within that definition, and that's stretching the concept of art beyond proportion.
Programming more closely resembles science, but I think it still falls short. Perhaps one can make a case for some design activities as scientific, but the actual development is rarely so. I may have a more pure definition of science than others, though.
Development is also a group activity, and, there, others of the listed metaphors seem to apply. Yet none of them seem quite right, either. I imagine that this is because group development is inherently complex, and the more singular something is, the less likely we are to find a suitable or useful metaphor for it. It's possible that development is sui generis, that it is similar only to itself.
It's also possible that no single metaphor can be found because every project is different. I've worked on projects with strong methodologies, and they did come close to being like a manufacturing process. I've worked on others which were virtual chaos, in which no rational person could find enough consistency to create a metaphor.
In the end, I guess I'm not sure why people try to create these types of metaphors, other than we seem to have a natural tendency to do so. I don't think I need a metaphor to understand what, say, a firefighter does; if I'm motivated, I'll learn about the job itself - no metaphor needed. The same is true of software development...if you have to ask, you'll never know (to paraphrase the great Louis Armstrong). In fact, these thoughts have fatigued me; I think I'll go put on some Hot Five.
No comments:
Post a Comment