ooops ... this is posted out of order because I "saved as draft" rather than "published".
My friend Rob pointed me to another little blog article about Software development being like / not like building bridges. The comments are revealing because they reveal that most people don't seem to appreciate the true value of analogies. They argue that the analogy is right or wrong, when the beauty of analogies is that they right AND wrong.
Analogies are powerful and useful because they make us think. They make us think because they force us, when we think about them, to contrast two different things - like bridge building, say, and software development. The contrast reveals where the analogy WORKS and where the analogy DOESN'T work. Both of these are useful.
I use analogies a lot. Possibly too much. I particularly like this one from an old sticky minds which contrasts the way a medical team, made up of complete strangers, formed when a guy had a heart attack on a ski slope with how software teams work. I recall that when I was writing it I spent a lot of time thinking about what the two situations had in common and then, near the end of the article, I thought "but it doesn't work entirely as an analogy, does it" because as soon as the helicopter left the scene, the team disbanded and none of them ever saw the patient again. I remember thinking that that's not true in most software development teams I've worked; most of them built the software, nursed it into life, then looked after it afterwards. I doubt the medics on the scene at the heart attack emergency would have behaved any differently had they then had to look after the patient in hospital, but it does make a big difference on software teams. My good friend Rob, a very senior technical manager for a very very big financial company, told me about stats he has which shows that the "cost of ownership" for the outsourced code is considerably higher than the cost of owning code that has been built in house, even though the outsourced code is cheaper to initially build. It's a lot like the difference between owning and renting a car ... another analogy.
What I've found is that almost anything can be used as an analogy. I'm looking around the room here, as I type, looking for something to use as an example. First off, I see my laptop's keyboard. Software development is a lot like typing. Is it? Well, there's a lot of typing in software development, and most typing is done with the purpose of producing something useful that is more than a collection of randomly typed characters. So there's thinking involved as well. Software dev and typing a blog post both involve thinking and typing. Now I look at the editor I'm using. It's the online version that comes with typepad, my blog host. It's a bit crappy and there are better alternatives. So software development involves typing, tools and thinking. But obviously, software development is more complicated than ordinary old typing; there are more connections; there are design considerations. But then I've just spent the last 4 years typing a book ... that's a damned site more complicated than writing a computer program. So, software development is a lot like writign a book! But, there is a difference - I wrote the book by myself, most software is developed (I think) by teams. But then again, teams can sometimes write a book. The pragmatic programming book was written by two people. So was Lean Software Development. The Goal had two authors and Goldratt's subsequent books had ghost writers or collaborative writers. And my book is now getting much better with the help of an editor (who acts a bit like a product owner and an inspector). So maybe they are quite similiar.
Time for a new paragraph. Now some books, with multiple authors, are easier than others. You break a book into chapters or esays which are independent of each other (loosely coupled) but share a common theme , throw in an editor, and you can produce a pretty good book - like Joel Spolskys recent anthologies. So design is important. My book - a business novel - is highly coupled and spaghetti like, in some respects, although it fits pretty much to the outline I wrote 4 years ago. Some things are easy to change - for instance renaming Paul to be Brutus, will be easy, but renaming Anne to be Brutus would be much harder. Wow! Some things in software are hard to change too. What do we do in software when things are hard to change? We either avoid those sorts of things or we make them easier. So in my book, if I thought I was going to change the sexes of my character's frequently then I'd design my book to make that easy! But I'm not ... and I'm getting bored with this analogy.
If you haven't notice, let me point out that almost everything you are reading here is off the top of my head. Analogies and Metaphores are hugely powerful for making you think ... that's all.
Oh and here's an edited version of the comment, that in real time, came before this, but was meant to come after. If that make sense ...
You've probably noticed loads of typos and spelling mistakes above. My apologies - no matter how much (or little, sometimes) I read these things I always make loads and loads of little mistakes. It probably bothers some people.
Not to my point: one of the ways that software development is differnt to writing is that YOU CAN TEST IF SOFTWARE WORKS against specifications, you can't do that with writing nearly as easily. Interesting that you can INSPECT both by reading and how having TWO different people INSPECT the same code/writing will probably spot more problems. But you can't execute your writing and say "Yes it works exactly as expected". That subtle distinction should make a huge difference to how we write software ... And it's one of the reasons why DEVELOPING software is a lot like DEVELOPING a new car - you need to road test each of the individual components and road-test the vehicle, before you start manufacturing it.
