Compromise is neither one thing nor another but something halfway in between, which often means in the middle of nowhere. Consider this variation on a classic example. Your team is designing a graphical user interface. One group strongly advocates placing the control buttons across the bottom of the screen, another is pushing for a panel down the left side. Between these horizontal and vertical extremes, a perfectly objective compromise can be struck: just place the buttons along a diagonal across the middle of the screen!

A compromise, like this one, is frequently worse than any of the original alternatives, but a consensus solution can be better than all of them. Technical compromises often fail to account for the merits in each of the alternatives, and their advantages are lost by taking some kind of average position. True consensus is not based on compromise, in which everyone and every position loses a little, but on synthesis, in which everyone wins big. The payoff, of course, is better software.

A synthesis is something original that incorporates essential features of each contributing idea or proposal. In the interface design example given above, it's easy to see a creative synthesis in which the placement of the button panel is an option selectable by the user. Not only does a consensus based on synthesis incorporate the best of the alternatives, but new features or capabilities typically emerge from the combination. Out of the synthesis of horizontal and vertical button panels might emerge end-user customization. The product thus incorporates the best of both worlds, not the worst.

Building real consensus is not easy, as politicians and labor negotiators know all too well. Building a technical consensus is a little different from building political consensus, but it has some of the same elements. Both take a commitment to working things out; both require a certain faith in the process.

Team members need to believe that it is possible to reach a technical synthesis incorporating the best elements and aspects of everyone's contributions. Believing this, they will stubbornly look for something better, rather than settle on compromise or cling needlessly to personal favorites. By persisting, they build their understanding of the problem and the nature of the strengths and weaknesses of each approach. From this, they enhance the odds of finding that creative something that exceeds them all.

Consensus design also works best when each of us believes that building a better piece of software is more important than getting our own favorite ideas into the result in some predetermined form. This investment in the quality of the outcome makes it easier to see the merits of whatever ideas emerge from the group process.

It helps, of course, if teamwork is applauded over individual pyrotechnics. Companies that reward individual performance instead of group success, or those that promote the lone wolf programmer over the team player, typically end up with a staff of uncompromising loners who probably will not and cannot play team sports. Such companies will rightly conclude that the best software is produced by their frontier-type geniuses. What they don't realize is that they've set it up to come out that way. Other outcomes are possible, of course.

One essential rule in building technical consensus is: No horse trading! Trading votes or support or influence is one of the classic tactics for political success, but it can destroy technical effectiveness. For example, we might work a trade in the interface design. I'll agree to your stupid idea of having the button panel across the bottom, if you agree to my clever design for icons without labels. The result is an interface that is less than the best in not one, but two features. Horse trading is just compromise in another disguise, but compromise made worse because decisions in one area contaminate those in another. Good technical consensus must see each issue as a separate problem, to be resolved on the merits, not as part of a point scoring system in which concessions in one area can be traded for obstinacy in another.

One likes to think that technical decisions are made on the basis of technical issues—facts, measurable quantities, practical considerations. The truth is that feelings, opinions, intuition, and just plain biases are part of any decision-making or problem-solving process involving people. This is the reality of what it is to be human, and although some people try to deny, control, or suppress these nonrational aspects, it never works completely.

An essential skill of any team that hopes to build technical consensus is to learn to separate fact from opinion. If the group, collectively, is to make the best decisions and solve problems creatively, they need access to the best information and to know what kind of information they have. Opinions aren't bad; team members should be able to express them freely. Opinions can even be useful, especially when weighted by hard-won experience, but they must not be confused with facts or data or analyses. Facts, too, have their limitations. In the areas of aesthetics or marketing appeal, facts may be in short supply. Unfortunately, once some group members have made up their minds, they do not want to be bothered by facts.

Calling something a fact doesn't make it so, and groups have to learn to cut through the bull and agree not to abuse the language. My first wife learned in our early years to be suspicious of any statement I made that started with something like, “The facts in the matter clearly indicate …” This was a warning that what followed was probably a bald-faced personal opinion unsupported by either data or evidence. Failing with this opening gambit, I was sometimes known to fall back on another tactic, which we came to know as the “Ninety-five-percent-of-all-scientists” move. Some of you may recognize it. “You know, the vast majority of professional software engineers, certainly more than ninety-five percent, favor this approach.” Of course, to have any hope of continued effectiveness with this clever ruse, you have to vary the percentages. “Nearly seventy-eight percent of WordPerfect users know that the one best way is …” “If we took a survey, better than two-thirds of C programmers would agree …” Sometimes it seems that if you squint just right you can almost see those legions of scientists or software engineers or end users lining up behind the speaker to lend support to his or her position.

But that's just my opinion.

From Computer Language Magazine, Volume 9, #4, April 1992.