Standardization is often promulgated as a worthy goal for teams and communities, but it must be recognized for what it is: a Platonic ideal. It is far more practical to simply constrain the number of options to a small number. Even then, you must be prepared to make an occasional exception simply to get the job done.

I don’t think chaos is the answer, where you end up with everyone doing something different. However, I don’t think totalitarian standardization is the answer, either.

It’s important to use the right tool for the job. And if the tool doesn’t exist, who’s to say it shouldn’t be created?

There are simply too many compromises—both in terms of community dynamics and software functionality—that have to be made in order to force everyone to use One Thing. In fact, the more code, people, and projects you have, the more compromises you will be forced to make.

People often justify draconian standardization efforts by invoking the cliché “reinventing the wheel”. In reality, this is almost always a false analogy. Can you imagine if we had stopped with this design?

When someone tells you “don’t reinvent the wheel,” they probably mean to say “don’t duplicate effort”, or “don’t repeat yourself” (DRY). The latter phrases avoid drawing a false analogy, but still have the problem of assuming that (1) duplicating effort is inherently bad, and (2) that the accused is guilty before being proven innocent.

As for (1), sometimes duplicating effort is a perfectly reasonable thing to do. Students recreate other people’s work all the time in order to learn. And in the process, they sometimes discover even better ways of doing things. Or they may find that one way happens to be more productive for some people than another way, simply due to psychological differences among individuals.

Regarding (2), maybe the accused is guilty and maybe they aren’t, but it makes a big difference whether or not you decide in advance that the person has nothing of value to add beyond what already exists.

Stephen Covey found in his research that highly successful people seek first to understand, and only then to be understood:

If you’re like most people, you probably seek first to be understood; you want to get your point across. And in doing so, you may ignore the other person completely, pretend that you’re listening, selectively hear only certain parts of the conversation or attentively focus on only the words being said, but miss the meaning entirely. So why does this happen? Because most people listen with the intent to reply, not to understand.

As you seek to understand another’s point of view, it helps to recognize that different things “feel” right to different people. When you standardize on One Thing, you gain some advantages with respect to knowledge and code reuse, but those are often offset by the loss in productivity that is inevitable when you force a significant portion of your community to use something that doesn’t feel natural to their way of thinking.

More importantly, by mandating One Thing, you dissuade people from experimenting with other things which may (or may not) some day prove to be better than the One Thing, or at least inform future revisions of the One Thing. I don’t pretend to know in advance what the Best Thing is, and neither should any other community member.

Indeed, community leaders should see themselves more as moderators, and less as presidents or dictators.

If you put Some Thing out there and let people try it, and you see, by its fruits, that it is Good, other teams will start picking it up. Before you know it, you’ll arrive at a natural standard. But this takes time. You must be patient. You must, as a community, experiment with Some Thing, pushing and prodding it from many different angles, discussing its merits and shortcomings. Not too much time; just enough to get an idea of Its practicality. Enough time to allow Darwin to do his job.

It is common to think “me vs. them”, but the most effective community leaders think “we” or “us”. They seek first to understand. Consider: was the project made for the process, or the process made for the project? Was the leader made for the community, or the community made for the leader?

If you have to push very hard to get people to adopt Your Thing, you are doing it wrong. You aren’t building the community; you are poisoning it.