If you accept the premise that software development is a cooperative game, then you might wonder: what kind of game is it?
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!
As a climber the metaphor is both good and bad.
On the one hand when you climb to the summit of a mountain you will probably never climb that mountain again.
On the other hand when you climb to the summit of a software project you may or may not climb that mountain again…
You can say all you want about the similarities between the two however there is one more striking difference between them.
You can die on a mountain. The stakes are for real and very high…
Waterfall, RUP, XP, Agile and now Crystal. You know, Jeff, you have done quite an 180 degree turn away from what you said previously:
the value of big-Em methodology decreases very sharply as you climb the skill ladder
What caused the turn?
Actually,
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.
So this is from memory and no coffee, just woke up.
I like Alistar’s work because he is not one of us. He has approached this as an anthropologist. He is not trying to invent a new way. He has tried to take what he has observed to work well.
So if this a reason that you too like his work you would probably like Organizational Patterns of Agile Software Development:
They too took the approach of an anthropologist. This book is very dense. Don’t let its size fool you, 419 pages. There is so much information in this book.
It used to be available on the web on their wiki at http://www.orgpatterns.com/
Smiles,
Jay
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.
this is a rather boring (sorry jeff) topic.
software projects are like many other things in the world, like many other things in the world.
we know what software projects are about. so the only value i extracted from the text is, that rock climbing could be a hobby for software developers. o_O
to eat a bratwurst is very much like to eat a hamburger btw.
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.
I think a better analogy would be that of a painter.
Some believe that painting requires real talent, yet even the talented study, learn and practice the art.
Others do not want to employ great artists, so they come up with a plan and reduce the project to painting by numbers.
Jeff,
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.
I’d also make the point that climbers don’t tend to have waistlines like programmers
I have used the climbing metaphor before, particuarly with regard to configuration management (version control):
as you go up you make frequent check-ins (or thread your rope through anchor points), so that if you fall it isn’t very far…
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?