Waterfall, RUP, XP, Agile and now Crystal. You know, Jeff, you have done quite an 180 degree turn away from what you said previously:

http://www.codinghorror.com/blog/archives/000203.html

"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.

Beam me up, Scotty:

http://weblog.raganwald.com/2006/05/beam-me-up-scotty.html

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
by James O. Coplien, Neil B. Harrison
http://www.amazon.com/Organizational-Patterns-Agile-Software-Development/dp/0131467409

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 (the book is a print of the wiki). Now I cat only find dead links. Like I said I just woke up so you go and find the wiki yourself.

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 metaphore 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 :) )

Quote: "Thus, the optimal strategies for a series of races are different than for a single race."
This reminds me of Dawkin's ESS (http://en.wikipedia.org/wiki/Evolutionarily_stable_strategy) 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.

> 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?

> This recent rock climbing metaphore is tenuous at best. I can make the same arguments for basically any professional endeavor.

Are you saying software projects are like a peanut butter sandwich?

http://www.codinghorror.com/blog/archives/000304.html

> Personally, I find his insights to be mostly useless in the real world.

The value of the metaphor is only useful insofar as it results in actionable things you can do in the real world, on your own project, that result in practical benefit. That's why I linked to his book on the Crystal Clear method. I'm curious, has anyone reading this tried it?

> You know, Jeff, you have done quite an 180 degree turn away from what you said previously: http://www.codinghorror.com/blog/archives/000203.html

I think you should be familiar with common methodologies, but that doesn't mean you have to be a slave to them.

> > You know, Jeff, you have done quite an 180 degree turn away from
> > what you said previously:
> > http://www.codinghorror.com/blog/archives/000203.html
>
> I think you should be familiar with common methodologies, but that
> doesn't mean you have to be a slave to them.

Right then, what is the Crystal Clear Method? So far we've heard about war, rock climbing, games and swamp races. But nothing at all about what this wonderful method really is.

Or do I have to buy the book to find out just what I'm getting? Come on, if you're going to bag a referral bonus from Amazon, the least you can do is to be an honest salesman and show us the real product we're supposed to buy. Or is the whole book a series of analogies with extreme sports?

Huh: only wimp-ass programmers sink bolt into natural rock: real programmers perserve their jobs with no comments, odd techniques, and as much assembly as possible!

Foob

What exactly is a 'chuck' when applied to rock climbing? ;-)

I happen to be a programmer, and am also a rock climber. I would say there is no comparison between the two, at least in my case. I climb for recreation, I might get to the top of something, but I just come back down.

When I am coding, I will create a feature, but I won't delete it (unless it really really sucks!) I create the feature so that other's can do that feature. I do not climb so that other people can benefit from it.

Refering to tools...I find several similarities between climbing and coding. Both of them have tools, and the tools can be used in more than one way. I beleive that there is no 'wrong' way to use any tools, but there are usually several 'better' ways to use a tool.

Anybody can climb to some point, as can anyone code. It does not just require having the knowledge, it depends on being able to implement your knowledge in the correct way to acheive your goal. Rock climbing requires enough strength to implement your teqnique, and coding requires enough knowledge to implement.

I would say they are probably about as similar as two different things can be, but that could be said about almost anything, as was mentioned above regarding ballet.

Cam Tardi

public class ClimbingOutOfCubicle
{

public static void main[String[] args]

{
if((waistline < MaximumWaistline) && !(carpeltunneltest))

{
ClimbOverWall();

}

public static void ClimbOverWall()
{
while(you.location != top)
{
Grap.Wall();
you.PullUp();
}

}

}

}

> 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.

Heh. :)
Well, it's always dangerous to take a metaphor too far. But, they *can* be useful to highlight aspects of a topic that might otherwise be hard to see (either because they're too abstract, or _because we're too familiar with them to actually think about them_).

Personally, i can't dance. I've never taken ballet, and the only experience i've had dancing in any form have involved massive quantities of alcohol. I'm not a rock climber either, but i have climbed rocks and can appreciate the value of skill, experience, and proper equipment. I've also spent a fair bit of time hiking through marshes, and making maps, and cutting trails...

Point is, as with any metaphor, YMMV. Gosh knows how many *football* metaphors have been wasted on me - but considering the popularity of the sport(s), i'm sure they have meaning to a fair number of other readers. Ya gotta just take what you can find...

I thought this thing was witty and sensible.

I am a former member of the Japan Expert Climbers' Club (which, despite its ridiculous name is a group of the best climbers on the face of the planet) and of the Groupe Alpine Internationale of Tokyo.

In the first I am one of the two or three least competent members. In the latter I and the excellent Wendy Holdenson, from Sweden, are the teachers, and we keep all the other members from accidentally killing themselves and each other.

The parallel with computer programming is as follows: some people are a thousand times as good as others -- in terms of lines of good code that they can produce before breakfast.

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...

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.

1. 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.

2. 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.

3. 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.

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".

For those who may be interested, I've posted links to a couple of sample chapters from the book here: http://www.agilekiwi.com/crystal_clear.htm

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.

I think I just figured this whole rock climbing thing out.

It's not a methodology. Because it doesn't really tell you anything unique.

It's a motivational speech.

Which explains why so many "manly" activities are used. If you can get your team to walk away thinking they're cool extreme dudes for writing that SQL then hey, motivation! Making them think they're "sissies" will probably not have the same productivity-boosting effect.

Today on the 'Metaphors Are Fun' channel:

Software Development is like ...

Cooking:

- A low barrier of entry means anyone can do it, leading to high variability of quality that can't be analysed until you try it.
- Methodologies are an aid, but in no way guarantee anything.
- The end result is not guaranteed in any way to be of any benefit to you.
- Sometimes, no matter how good you are, you will burn the souffle.

Hmm... peanuts. I mean, souffle.

The point of metaphor is to take a process that is complex and bring it to a common, more understood level that is not-so complex. Perhaps, even to gain more understanding of the complex subject by extending the metaphor. The problem comes with bad metaphors that are extended and don't lend additional insight into what the author is comparing against.

The biggest problem I have with a rock climbing metaphor is that it isn't really a 'common' thing. How does a rock climbing metaphor help me understand the process of software development? Really, all that has happened is that you (Allistar, I suppose) has transferred things he knows about development to a sport he enjoys.

The building metaphor, tried and true, still goes a lot further. You can put together a dog house without a plan and even if you mess it up, it isn't a big deal to tear it apart and redo the whole thing. You really need a blueprint for a house, though. Moving an interior wall can be difficult after the house is built. That kind of thing is easy to translate to our daily jobs, in my opinion.

g

I find it ridiculous that Rock climbing is a manly sport, my 6 year old daughter outclimbs most adult males who act all macho and have little experience and some of the greatest achievements in climbing have been accomplished by women.(See Lynn Hill and her first free ascent of the nose El Capitan and then her follow up first free ascent of the nose in a day). I dont know much about programming but I assume the point of a metaphor is to draw similarities so that people can understand them on their own terms. If not many programmers are rock climbers this may not be a good example.
P.S. A chock is a form of protection wedged into the rock that a sling and carabiner are attached to that the climbers rope is clipped through for protection.

I only wish there were more women programmers.....smokin hot women progammers.

Oh..K. How does this rock climbing analogy hold for software testing phase?

In my opinion the most realistic metaphor is Sport Climbing == Programming:

It's fun, it's not dangerous, it's technical but you only need strictly technical skills, you have to know your tools, but you need to know only the ones you really need, you don't need to plan a lot because the route has already been setup by someone else, and it's not very team oriented.

http://codeclimber.net.nz/archive/2007/04/05/Software-development-like-which-climbing.aspx

what is it called when you get stuck and you cant climb down or up?

Being a rock climber and a programmer. I found the analogy to be very true due to the trials encountered while performing each activity.

One day while climbing with a buddy of mine we decided to follow this beautiful dihedral to the summit of a 400ft granite wall. Now don't let me fool you this was not the hardest 400ft climb you could do. That is until we were about 100ft from the summit, we hit a large overhang that provided very little in terms of protection. So here was our dilemma we were to far up to go back and reevaluate our plan, so we had to adjust it. We ended up finding a line to the right that provided safety to navigate around the overhang.

So In Comparison to Software Engineering:

There have been times as a developer that I approach a particular situation with a plan in mind. Then I come to a point where that plan is no longer 100% effective, so I must adjust.

Software projects are more like piece of art than adventure sport.

I think the reason some people are bored of analogies like this is that they are already software developers. One of our strengths, even if we do not realize it, it analogies. We really are writing an analogy every time we make code match a business requirement. We are good at it. Therefore, we do not find them to be very clever.

Likewise, one of our common faults is a lack of seeing things from a different perspective. So while articles like this could inspire epiphanies from our management, some of us tend to just be bored, instead of saying, "Yes, this is correct. Let me forward it to my boss to help enlighten the fool... erm, I mean... the guy."

its very great thanks