Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 2. Individuals Overcoming Failure Modes
-
Часть 2
-
This characteristic, "preferring to fail conservatively rather than to risk succeeding differently, " gets coupled with people's fear of rejection and the difficulty they have in building new work habits. The three together explain (to me) why managers continue to use the long-abused one-pass waterfall development process. Based on this line of thinking, I expect that people will continue to use the waterfall process even in the presence of mounting evidence against it and increasing evidence supporting incremental and iterative development. The line of thinking that perpetuates the use of the waterfall process is anchored in a failure mode.
In keeping with variations among people, some people have the opposite tendency. Often, though, the most adventuresome people are those who have little to lose personally if the project fails.
The good news is that there are opportunities for both sorts of people. The bad news is that these people probably find themselves on the same project.
Inventing Rather than Researching
This behavioral mode may be peculiar to American and European software developers (I don't have enough experience with Indian and Asian developers to comment on their habits). It is the tendency to avoid researching previous solutions to a problem and just invent a new solution on the spot.
This tendency is usually described as a sickness, the Not-Invented-Here (NIH) syndrome. I prefer not to view it as a disease but rather as a natural outgrowth of cultural pressures. One might instead call it the Invent-Here-Now Imperative. It grows in the following way:
From earliest school days, students are instructed not to copy other people's work, to not help each other, and to be as original as possible in all but rote memory acts. They are given positive marks for originality and punished for using other people's solutions. (Recently, a fourth grade teacher told her students not to call each other to discuss homework problems—not even to ask for which problems to do! ).
Through the university level, assignments are designed to produce grades for individual work, not for teamwork. This reaches a culmination in the Ph. D. dissertation, where originality is a core requirement.
Somewhere in these years of schooling, some people join the profession of "programmer, " a person whose job is to program and who advances in the profession by writing harder and more uniquely original programs.
Under these circumstances, it is hardly surprising that the people internalize the Invent-Here-Now Imperative.
Upon showing up at work, though, these same people are told by the business owners that they should not write new programs but should scavenge solutions created throughout the industry over the history of the field. They should use as many existing solutions as possible, without violating intellectual property rights.
The rewards offered for this behavior are meager. People continue to receive low evaluations for reusing code instead of writing new code. Promotion comes to those who do the most and the best programming, not those who successfully hook together existing components. Technical authors still refer to people who do such work as low-level "component assemblers. "
In one survey, education and attitude showed the greatest correlation with increased reuse (Frakes 1995). Just being shown that reuse was culturally considered a preferable outcome over developing new solutions [this phrase, which is not yet a complete sentence. ]. Reward structures did not show a significant effect, nor did object-oriented technology, CASE tools, or a myriad of other factors.
Texas Instruments fought its "Not Invented Here" syndrome with an unusual award, the "Not Invented Here But I Did It Anyway" award (Dixon 2000). This NIHBIDIA award not only rewards people who make use of previous results, but it pokes fun at people caught up in the NIH syndrome at the same time. In this way, it creates a social effect of the type Frakes and Fox were referring to.
People who are professionals in some different field do practice effective reuse. These people, using the computer to accomplish some assignment of value in that other field, develop their sense of accomplishment from the program's effect in that other field, not from the cleverness of the programming. They are therefore motivated to put the software together to get on with their other work. They happily accept a less glamorous design if it can be put into use quickly.
Inconsistent Creatures of Habits
Asking a person to change his habits or to be consistent in action are the two most difficult requests I can think of. We are creatures of habit who resist learning new behaviors, and at the same time we tend toward inconsistency.
This may seem like a harsh judgement, and so I illustrate it with a conversation I heard between four people. Each was a senior manager or had a Ph. D. , and so these were people you would most expect to be able to handle changing habits and being consistent. The Clean Desk Technique
One of the four said, "I'm suffering from the flood of paper that comes into my office. I can't think of how to manage it. " A second offered, "It's easy. Keep your desk entirely clean. Put four baskets on one side and a set of folders in the top drawer. When a new piece of paper shows up, deal with it directly, and put it into its correct filing place. .. " He didn't actually get that far before the other three jumped in together: "Keep the desk clean! ? I can't do that! " The second speaker never got to finish explaining his technique. The demand was that the people act with care at 100% consistency. A few people can accomplish this. Most people, though, vary from hour to hour, having a good hour followed by a bad one. Some people even celebrate being inconsistent and careless.
Worse than asking them to be consistent, the second speaker asked them to both change their habits and be consistent in that change.
This story tells me, as a methodologist, that if we ever do discover an optimal design process, people will resist using it and then use it sporadically or carelessly.
If only people could just act consistently. .. Of course, if they could do that, they could keep their desks clean, avoid cavities, lose weight, give up smoking, play a musical instrument, and possibly even produce software on a regular and timely basis. We already know of a number of good practices.
David Gries detailed how to derive correct programs in The Science of Programming (1987).
Beck and Cunningham (1987) and Wilkinson (1995) described using CRC cards in object-oriented design.
-
Закладки
The main question is, if you were funding this project,…
It follows that on the Theory Building View, for the primary…
The complete discussion about when and where to apply…
Agility implies maneuverability, a characteristic that is more…
After much coaching for six months, his programs still…
The industry is littered with projects whose sponsors did not…
While writing, reading, typing, or talking, we pick up traces…
Games are not just for children, although children also…
Accepting program modifications demanded by changing external…
Walk around your place of work. Notice · The convection currents…
The group of 17 quickly agreed on those value choices.…
Figure 4-1. Elements of a methodology. Roles. Who you…
1. Project name, job of person interviewed (the interviewee…
We see an example of needing these normalizing rituals in…
The third problem is absence of feedback from the downstream…
The surprising thing about human success modes is how…