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.
Beck (1999) and Jeffries (2000) described pair programming and test-first design in the context of Extreme Programming.
Careful design checking and statistical testing were detailed in the Cleanroom methodology (Becker 1996).
Humphreys (1996), in his Personal Software Process, provided detailed instructions about how programmers can become more effective through checking where errors are introduced.
Consistent application of any of the above ideas would improve most of the projects I have visited. As Karl Wiegers quipped, "We are not short on practices; we are short on practice."
Countering with Discipline and Tolerance
Methodologists deal with people's common weaknesses with tolerance or discipline:
· Design the methodology to be tolerant of individual variations.
· Create mechanisms in the methodology that hold strict behavioral standards in place.
Most choose discipline.
Because consistency in action is a human weakness, high-discipline methodologies are fragile. Even when they contain good practices, people are unlikely to keep performing those practices over time. Performing a disciplined activity daily is just as hard in software development as keeping the desk clear in the clean-desk technique just mentioned.
To remain in practice, a high-discipline methodology must contain specific element(s) that keep the discipline in place.
Let's look briefly at three high-discipline methodologies: Cleanroom, Personal Software Process, and Extreme Programming.
In Cleanroom, production code is not allowed to be compiled before being checked in. Typing errors and syntax errors are considered part of the statistical process being controlled (new language features and system calls are learned on nonproduction code). The team doing the compiling can then detect the rate at which errors are introduced during program entry.
This is a high-discipline rule and requires explicit management support and checks.
In the Personal Software Process, the practitioner is to write down how long each activity took and to tabulate at what point errors got introduced. From these notes, the person can determine which activities are most error-prone and concentrate more carefully next time. The difficulty is, of course, that the logs take effort to maintain, requiring consistency of action over time. Not producing them properly invalidates PSP.
PSP contains no specific mechanisms to hold the high-discipline practices in place. It is, therefore, not terribly surprising to find the following experience report coming from even a highly disciplined development group. The following words about PSP were written by a military group that had been trained in PSP and had achieved the Software Engineering Institute's Capability Maturity Model Level 5 rating (Webb 1999):
PSP Report
During the summer of 1996, TIS introduced the PSP to a small group of software engineers. Although the training was generally well received, use of the PSP in TIS started to decline as soon as the classes were completed. Soon, none of the engineers who had been instructed in PSP techniques was using them on the job.
When asked why, the reason was almost unanimous: "PSP is extremely rigorous, and if no one is asking for my data, it's easier to do it the old way."
Extreme Programming is the third methodology to call for high-discipline practices. It calls for programming in pairs (with pair rotation), extensive and automated unit tests completed prior to code check-in each day, adherence to the group's coding standards, and aggressive refactoring of the code base.
Based on the discussion above, I expected to find adherence to the XP practices to be short-lived in most groups. My interview results were somewhat surprising, though.
People report programming in pairs to be enjoyable. They therefore program in pairs quite happily, after they adapt to each other's quirks. While programming in pairs, they find it easier to talk each other into writing the test cases and adhere to the coding standards.
The main part of XP that is high-discipline and resistant to the pressure of programming in pairs is the code refactoring work. I still find that most people on the team do not refactor often, generally leaving that to the senior project person.
However, unlike PSP, Extreme Programming contains a specific mechanism to help with the discipline. It calls for one person to act as "coach" and keep the team sensitive to the way in which they are using the practices.
It is interesting to note that all three of these methodologies were invented by people who were, themselves, consistent in the habits they required. So it is not as though high-discipline methods can't be used. They just are "fragile."
The alternative to requiring discipline is being tolerant of individual variation.
Adaptive Software Development (Highsmith 2000) and the Crystal methodology family described in this book (Cockburn 2002) are the only two methodologies I know that are explicitly about being "variation tolerant." Each methodology calls for the
Reminding ourselves that people vary, that certain broad generalizations hold, and that there are exceptions team members to form consensus on the minimum compliance needed in the work products and practices. Each suggests the use of standards but does require that standards be enforced.
For "tolerant" methodologies to work, the people on the project must care about citizenship issues and generally take pride in their work. In such projects, the people develop a personal interest in seeing that their work is acceptable. Getting this to happen is no more guaranteed than getting people to follow standards, but I do see it accomplished regularly. It was also reported by Dixon (2000, p.32).
Which is better: high-discipline or high-tolerance methodologies?
· Strict adherence to strict (and effective) practices should be harder to attain but may be more productive in the end.
· Tolerant practices should be easier to get adopted but may be less productive.
Part of the difficulty in choosing between them is that there currently is no consensus as to which practices are effective or ineffective under various circumstances. As a result, project leaders might enforce strict adherence to practices they considered effective and be surprised at the negative result they encounter.
The "Continuous Redocumentation" story in the last chapter gave one example of false adherence to discipline. The sponsors required that every change to any part of the system be immediately reflected in all documentation. They probably thought this would be an effective practice. In their context, though, it proved too costly, and the project was canceled.
In other words, while strict adherence to effective practices leads to an effective team, strict adherence to ineffective practices leads to an ineffective team.
If only we knew which was which. To each generalization, let's look at some of people's natural ways of working.
People generally work better by starting with something concrete and tangible, such as examples, by altering rather than creating from scratch, by watching, and by getting feedback.
One of my favorite sentences comes from Wenger and Lave (1993) about the power of the concrete:
“The world carries its own structure, so that specificity always implies generality (and in this sense, generality is not to be assimilated to abstractness). That is why stories can be so powerful in conveying ideas, often more so than an articulation of the idea itself.”
Concrete
Cognitive research provides support for the idea that our minds operate directly from concrete examples (an idea that is remarkably in harmony with the properties of neural networks).
Johnson-Laird and Byrne (1991) suggest that people perform logical deduction by imagining concrete situations and concrete counterexamples rather than from manipulating predicate calculus in their heads. For example, in a problem about billiard balls, "it is possible to frame rules that capture [the] inference, but it seems likely that people will make it by imagining the layout of the balls."
They suggest that in performing deduction, we: [Au: Use a numbered list,]
Construct an internal model of the state of affairs that the premises describe