

Consensus-Driven Development - steverydz
http://www.nczonline.net/blog/2015/04/14/consensus-driven-development/

======
piptastic
Personal anecdote:

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.

------
tikhonj
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.

------
kazinator
This is another name for "design by committee".

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).

------
firasd
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.

------
consensusdevel
Consensus is not always good or always bad. When to use it depends on the
situation. Here's an article explaining:

\- [http://sloanreview.mit.edu/article/when-consensus-hurts-
the-...](http://sloanreview.mit.edu/article/when-consensus-hurts-the-company/)
[paywalled]

\- [http://ssrn.com/abstract=2579745](http://ssrn.com/abstract=2579745) [open
access]

