Software Development as a Cooperative Game

Software development has been compared to with different engineering disciplines ... mostly without success. Its been compared to bridge building, with automobile construction etc. Then, the big bosses, try to put in that methodology into Software development - with spectacular failure. And instead of finding a fault in the methodology or the 'Process' they are more liable to blame the people.

I think its cause of a) They not understanding the field , b) their big EGOs.

Unfortunately, if you work in a mid or big level organization, you are going to suffer these people, as they have mostly made their way up by sucking up and playing politics, not really by understanding how things work. Another reason is because they have been looking at all the wrong places to figure out how software works.

Alistair Cockburn has a fantastic article on what Software Development is all about. He compares it with Rock Climbing and I must say that it fits in better than any other theories I have read.

FTA:

I would like you to consider software development as a cooperative, finite, goal-seeking, group game.

Then he explains in terms of Rock Climbing ( i did rock climbing a long way back so the explanations were like 'let there be light' kind of revelation). The main comparisons from the article are :

Rock climbing is Technical. The rock climber must have technical proficiency. The novice can only approach simple climbs. With practice, the climber can attack more and more difficult climbs. The better rock climber can simply do things that the others cannot. Similarly, software development is technical and requires technical proficiency, and there is a frank difference in what a more skilled person can do compared with a less skilled person.

Training. Rock climbers are continually training and searching for new techniques they can use, just as software designers do.

Technical Pass/Fail. A key point of comparison between rock climbing and software development, for me, is that not just any solution will do. The climbers must actually support their weight on their hand and feet; the software must actually run and produce reasonably accurate answers. This key characteristic is missing from most alternative activities that people select to compare software development with.

Individual and Team. Some people just naturally climb better than others. Some people will never handle certain climbs. At each moment on the climb, the person is drawing on their own capabilities, have to hold up their own weight. The same is true in software.

And yet, climbing is usually done in teams. There are a solo climbers, but they are in the minority. Under normal circumstances, climbers form a team for the purpose of a climb and the team has to actually work together to accomplish the climb. Similarly, software developers, while working on their individual assignments, must function as a team to get the software out. The "Team - Individual" dual aspects of software development form the basis for most of my current work in methodologies, and I'll get back to it before I'm done.

Tools. Tools are a requirement for serious rock-climbing: chalk, chucks, harness, rope, caribeener, and so on. It is important to be able to reach for the right tool for the right moment. It is possible to climb very small distances with no tools. The longer the climb, the more critical the tool selection is. You software developers will recognize this. When you need a performance profiler, you really need it. You can't funtion without the compiler. The team gets stuck without the version control system. And so on.

Planning and Improvising. Whether bouldering, doing a single-rope climb, or a multi-day climb, the climbers always make some sort of a plan. The longer the climb, the more extensive the plan must be, even though the team knows that the plan will be insufficient, and wrong in places.

Unforeseen, unforeseeable and purely chance obstacles are certain to show up on even the most meticulously planned climbing expeditions, unless the climb is short and the people have already done it several times before. Therefore, the climbers must be prepared to change their plans, to improvise, at a moment's notice.

This dichotomy is part of what makes software development manages gnash their teeth. They want a plan, but have to deal with unforeseen difficulties. It is one of the reasons why incremental development is so critical to project success. (Does that sound like climbing in stages, and setting various base camps?)

Fun. Climbers climb because it is fun. Climbers experience a sense of flow while climbing, and this total occupation is part of what makes it fun. Similarly, programmers typically enjoy their work, and part of that enjoyment is getting into the flow of designing or programming. Flow in the case of rock climbing is both physical and mental. Flow in the case of programming is purely mental.

Challenging. Climbers climb because there is a challenge - can they really make it to the top? Most programmers crave this challenge, too. If programmers do not find their assignment challenging, they may quit, or start embellishing the system with design elements they find challenging.

Resource-limited. Rock climbing works against a time and energy budget, needing to be completed before the team is too tired, before the food runs out, by nightfall or before the snows come. In general, climbers plan their climbs to fit a resource budget. Similarly, commercial software development is governed by budget and need. It is in this sense that open-source development is different from commercial software development.

Dangerous. If you fall wrong on a rock climb, you can die or get maimed. This is probably the one aspect of rock climbing that does not transfer to software development. Rock climbers are fond of saying that climbing with proper care is less dangerous than driving a car. However, I have never heard programmers need to even compare the danger of programming with the danger of driving a car or crossing the street.

Have fun reading the article here (its quite long).