The big thing missing from your metaphor is everybody other than the programmers. If rock climbing were like programming, you would have management to change the course and destination periodically through the climb and marketers announcing to the world you will soon reach the top of Everest.
Also, as someone who has been both a developer and a sysadmin responsible for managing deployed code, this comparison reinforces the all-too common developer mindset that coding a given app is something you do once for a thrill, then leave behind to find the next challenge.
Sorry Jeff, I see the metaphor was Alistair’s, not yours!
When you climb a wall for the first time, you need to document, grade and depending the place also to bolt the protection on the wall, making it easier for other people to do what you have done. As more people climb it, more protection would be added, it will be better cleaned of loose rocks, new variants can be made, the documentation updated, the grade refined, etc.
So usually it builds on top of what its being build.
That’s the great thing about the human mind. You can compare anything to anything else and your mind will find similarities. For example, I will compare software development to an orange.
At first, sometimes development of a piece of software looks simple, just like an orange will at first look like an orange-colored sphere. However, upon further inspection, we notice complexities. In the case of the orange, we notice the dimples on the surface and the stem. In the case of software, we notice the restrictions on input and output and target execution environment.
When software works correctly, it appears simple. However, there is always a lot going on underneath the surface, hidden from the user. Similarly, an orange has a skin on the outside. All the meat of the orange is hidden underneath this skin.
Software development can be modular, splitting development between different teams. However, there is always a single construct that needs to bind all the pieces together for the system to function correctly. Similarly, in an orange, the slices of the internal meat seem disconnected and independent, but they are actually bound together by a thread running through the center of the orange.
That’s all I can come up with now. I think I’ve made my point, you can compare anything complex to anything else complex and your brain will fill in the details.
There are probably more metaphores for software development than for any other discipline.
Software development is like a game. No, it’s like a race. Or maybe it’s like building a building? Or maybe like building a bridge? Rock climbing? check. A battlefield? done this last week.
Metaphores can be very useful, but as we go down the list they seem to be less and less useful. The most useful one I know is the building metaphore, that is probably the most cited (for example, in Code Perfect, which also warns against useless metaphores).
Did you notice that these metaphores always tend to be “manly” ones? As if software developers suffer for some sort of infiriority complex, and are compensating by comparing them to military endeavors and exciting sports. No one ever compares software development to synchronized swimming, or group ballet dance for some reason. I wonder why? It also seems as likely as not that the person comparing development to X knows very little about X, and certainly is no expert about X.
This recent rock climbing metaphor is tenuous at best. I can make the same arguments for basically any professional endeavor. Let’s go with ballet dancing (which I know nothing about, but at least I tell you that):
Technical. The novice can only approach simple dances. With practice, the dancer can attack more and more difficult movements…
Tools. Tools are a requirement for serious ballet dancing: shoes, appropriate stage, clothing, practice equipment, and so on…
Planning and Improvising. Of course, each group performing Swan Lake approaches it with serious instructions, and yet every member contributes their own unique interpretation of things.
Fun. Dancers dance because it is fun…
Challenging. Dancers dance because there is a challenge. Can they really make it to the top (pun intended)?
Resource-limited. Ballet dancing works against a time and energy budget. The performance must be ready and rehearsed it’s time to perform, before the money runs out.
I’ll stop here, though I could conjure up more similarities.
My point is that many things are a lot like other things. Let’s stop making useless metaphores, and concentrate on those that seem unique, and actually contribute something to our understanding of ballet dancing. I mean, software development.
I used to work as an industrial automation programmer, using the same kind of tools and applications used in places like nuclear plants. Some jobs could be very stressful, as if you messed up your program a robot could potentially go haywire. Some jobs we turned down for the simple reason that if we made a mistake, someone could be seriously injured or killed.
So yes, programming can be very dangerous
(The vast majority of the work was a huge amount of fun though - it’s immensley satisfying to execute your program and see a car plant assembly line or a wine bottling line start up )
Thus, the optimal strategies for a series of races are different than for a single race.
This reminds me of Dawkin’s ESS
and an interesting observation. If you know the number of races in advance then your best strategy would be to not cooperate in the last race as you have nothing to fear from retaliation in the next race. Considering this fact - you can be reasonably sure everyone else will do the same so your best strategy would be to not cooperate in the next to last race, etc…
So knowing the number of races naturally changes the nature of the game considerably.
You asked who’s using Crystal. I use a “Crystal-like” process. I.e. based on Crystal with ideas borrowed from a few other agile processes too.
But, that’s not the real answer to your question. The real answer is that people were using Crystal long before it was written down. That’s because, as noted above, it was developed with an “anthropololgists” mindset. Alistair studied lots of teams, then distilled the common ingredients of their success into Crystal. His work is documented in his PhD Dissertation, which is available on his site.
Many experienced developers will read the book and think, “Hey, that’s what I’m doing already.” They may find it reassuring to know that so many other teams are succeeding in similar ways. They may also find useful ideas to add to their “bag of tricks”.
If you liked the Crystal Clear book, you’ll probably also like the new second edition release of his “Agile Software Development” book. It includes almost a book’s-worth of brand new material.
Did you notice that these metaphores always tend to be “manly” ones? As if software developers suffer for some sort of infiriority complex, and are compensating by comparing them to military endeavors and exciting sports.
If this blog had a moderation / rating system, that would be “+1 Embarrassingly True”.
I personally think software is akin to War. There’s a lot of screaming and confusion, you seem to tackle the same problems again and again, and at the end of the day you’ve accomplished something… but you’re usually not exactly sure what.
Geez, if you like Alistair so much, you should have been in my Software Engineering class. The class wasn’t taught by Alistair but was designed by him and he gave several guest lectures. I wasn’t aware we were being taught by such a celebrity.
Personally, I find his insights to be mostly useless in the real world. Sure, it’s good to try to do some of the things that he lays out but in my experience, it just doesn’t fit too well when you’re actually in the trenches.
Most “theory” doesn’t fit well in the real world. But it’s the ability to take something theoretical and apply it to the real world that marks your ability to leap logical gaps. It can’t all be laid out for you. If it were, well, we’d never breed another generation of thinkers, would we?