The Ultimate Software Development Metaphor?
For decades software development practitioners try to find the ultimate software development metaphor. This is not merely an academic discussion. If we can find a good metaphor for software development we might actually learn something from it. We can make analogies and try to apply things we already know about our world to software development in order to work better and improve our practices.
The most common metaphors in this context are probably construction, manufacturing, and art. None of them really captures the essence of software development. But more important, I don’t think any of them help us do our work better. If software development is an art, should I work like Picasso did? Should I design the product like Shakespeare created the outline for his plays? If software development is like construction, should it be as rigid as a building? And if software development is like manufacturing, are we supposed to do the same mechanical thing over and over again as if we work in an assembly line?
In a recent post Tom Harris tries once again to come up with a software development metaphor. No luck this time either. But the most interesting thing about this post is its title: Not Like Anything You’ve Ever Seen. I don’t know if this was what Tom actually meant, but I think we should consider taking this title literally. Maybe software development is indeed not like any other craft we know. Maybe our attempts to find the ultimate software development metaphor are futile.
I, for one, have yet found a good metaphor that captures what software development should be like. Finding a metaphor that captures this process, its complexity, and all the interactions which are part of it, might not be a practical thing to do. Maybe we need a different approach.
A more practical approach might be to try to come up with metaphors for smaller processes, phenomena, problems and solutions instead of trying to find the ultimate metaphor for software development as a whole.
Let’s give it a try…
Software Development is Like… Broken Telephone
Well, it isn’t really, but one of its major problems is. One of the major problems we face is passing information and managing it. Information flows from customers to marketing people, from marketing people to product managers and architects, and from there to team leaders, developers and testers. Information should also flow among developers and among testers. Information also flows backwards. And information flow also has a temporal axis.
Many of the problems we face in software development can be traced back to a communication problem: pieces of information which got lost or became corrupted when passed from one person to another. Problems in communicating requirements, design decisions, implicit assumptions, implementation details, estimations — you name it — lead to growing development costs and even failed projects. As software becomes more complex, this problem becomes even more acute.
Just like in the game, information become corrupted unless carefully handled. Sometimes information just fades away. This metaphor can help us isolate the problem, explain it, demonstrate it, and even have some fun with. When trying to describe software development as a whole using a metaphor, this problem might never catch our attention. But it is real, and it is severe enough for us to do something about it.
The Broken Telephone metaphor can also help us analyze potential solutions. For example, having the customer on site and promoting direct communication between team members might partially solve the problem for the short run. But if you consider a variant to the game in which the message needs to be recreated in a week from now, you might find that these means are not sufficient. When you add a temporal axis to the game, you have to do more than just speak directly with the person currently working on a certain task.
***
This is just one example of a smaller scope metaphor, which might have a greater value for us when trying to understand the problems we face and to come up with ideas to solve them. Intellectually fighting over the ultimate software development metaphor has yet managed to make a significant improvement in the way we create software. It might never will.
July 17th, 2006 at 9:02 am
Good, till now I have frequently used the “gardener” metaphor, but it worked only for bigger and longer projects (growing plants, new plants, need to cut branches, etc.)
July 17th, 2006 at 10:24 am
I like the broken telephone metaphore. It made me think of other childhood games that could be used as a metaphor for SD. How about Jump Rope–if two seperate groups of of SD stakeholders who are controlling the ropes don’t use the same chat and are out of rhythm the group in the middle is going to get tangled in the rope or fall over. For example, if Senior IT Mgmt is telling you to do one thing and Marketing is wanting something else, IT Development teams can get stuck in the middle tangled in the rope or falling over.
July 17th, 2006 at 11:23 am
Hi Greg,
That’s indeed a great metaphor for yet another common problem.
If any of you has more ideas for useful metaphors for sub processes, common problems, and phenomena, please feel free to post it here. I might just consider creating a dedicated page for such metaphors.
Lidor
July 21st, 2006 at 9:41 pm
[…] Software development is alien to a lot of people and explaining it in technical terms really makes it worse. So, we use metaphors. Lidor Wyssocky says it is like a broken telephone. And there have been many more attempts, to compare it with the construction industry with similar roles - architect, designer, developer (?) or manufacturing. Here is my attempt. […]