At one of the first programming companies I started at, there were no coding/database standards. When we decided we needed them, we appointed a few people to go over all the commonly used standards and present them to the group.
As we went over each standard, we either accepted it, rejected it, or proposed alternatives as a group. Often, we would have multiple people arguing different sides over each issue. Generally, it was just a case of someone being used to doing things a certain way, but having no real justifiable reason. In those cases we ended up voting on the outcome.
In the end, we had pretty good standards (in my opinion). While this wasn't consensus-driven, it ended up being strongly accepted in the company. I think this was because everyone was involved in the process, and you had a positive say in at least 1 or 2 of the standards that made it. Of course, eventually we added commit hooks to sniff out if you weren't following the standards :p
Sorry, there's no real point I'm making here...
Every company since then (except my current one), management just "decides" how standards/processes are going to be and announces it. Those usually ended up not being adopted.
Perhaps less about programming and more about society, I'm really not a fan of simple "majority rules democracy" or consensus building—which feels more like an enhanced version of the former than a distinct approach. Either approach is, in its own way, autocratic and ultimately bulldozes over anyone whose views and preferences don't match up well enough.
Instead, I'm fascinated with systems designed to robustly let people actively disagree but still coexist and work together. The goal is not to sway people's views or push them in a certain direction, but to allow different people to hold to different, possibly conflicting, outlooks and still coexist peacefully and productively. This way, even if you hold some minority preferences—everyone is different, so this is not a surprise—you're still free to do your thing.
That's, coincidentally, one of the reasons I'm a fan of some sort of capitalism: capitalism manages to optimize for everyone without needing a single goal handed down from above—or passed up from below. In a word: decentralization.
And you know, this could be applied to software too. Why does everyone at your company need to do everything in the same way? Sure, you'll get some minor advantages in compatibility, and it will be easier for people to move from project to project, but those advantages are limited—but very visible. I believe they're overvalued for just this reason: experience pushes people away from problems that are clear but not ones that are subtle.
So, from this point of view, I really like how some modern companies (Facebook and Prezi come to mind) are starting to organize small teams in self-contained ways. You expose and support a particular interface to the rest of the company, but can use whatever languages and whatever technologies you want internally. Then, instead of the whole company being a big, uniform blob of interconnections, you have a disparate network of self-contained systems with clear interfaces.
With this approach, each team can work with whatever technology fits their problem—and them—best. Moreover, you get the advantages of low coupling within your internal technologies, because the teams are, by necessity, distinct.
Now all this needs is a catchy name to rival "consensus-driven development". "Decentralized development", perhaps? It's alliterative.
The best systems are designed by one hacker working alone, or a small team who share the same vision. (Or if they don't, then the system only reflects a small number of visions integrated into a coherent whole.)
Rather than "take the temperature out of the room", what you want is "go to a different room" (where you can just write code).
Good article. I’m planning to write about conflicts in product choices soon and will reference this. Given that it’s a common and important issue, I tend to see relatively few articles on contention in teams about code and features (Michael Lopp a.k.a Rands in Repose does cover this topic in his writings.) For me it’s one of the most emotional and cognitively intense parts of working on digital products, and requires seriously engaging one’s analytical and communication skills.
At one of the first programming companies I started at, there were no coding/database standards. When we decided we needed them, we appointed a few people to go over all the commonly used standards and present them to the group.
As we went over each standard, we either accepted it, rejected it, or proposed alternatives as a group. Often, we would have multiple people arguing different sides over each issue. Generally, it was just a case of someone being used to doing things a certain way, but having no real justifiable reason. In those cases we ended up voting on the outcome.
In the end, we had pretty good standards (in my opinion). While this wasn't consensus-driven, it ended up being strongly accepted in the company. I think this was because everyone was involved in the process, and you had a positive say in at least 1 or 2 of the standards that made it. Of course, eventually we added commit hooks to sniff out if you weren't following the standards :p
Sorry, there's no real point I'm making here...
Every company since then (except my current one), management just "decides" how standards/processes are going to be and announces it. Those usually ended up not being adopted.