I would love to see the results/conclusion of this research. We would finally get some data-backed insight into why/why not democracy is good for a software project.
Your thinking is underlined by assumption there is one correct solution to arrive at. But maybe that's actually rarely the case.
* The theorem doesn't directly apply to decisions between more than two outcomes. """
Additionally, it does not take into account the cost of making the decision, which, under direct democracy, rises quadratically with the number of people that must debate and agree to the decision.
I think you would find, if you have n options, one of them is the correct one, and there is slight bias towards the correct one among the decision-makers, a similar theorem still holds (from the central limit theorem).
Regarding the transaction costs, this is a different issue, but I would say that is an issue in any project regardless how things are decided. Nothing in the theorem itself requires the people to actually communicate, they can just become biased towards the correct solution on their own.
It should be also noted that, in the real world, people can decide not to take the vote if they don't feel qualified to decide, further improving the results of the theorem.
(I actually rediscovered the CJT myself when I was interested in how democracy works.)
I think it would be nice to try this on college students, give them some knowledge test (or perhaps two - one in their area of expertise and the other outside their area), and compare the best individual results with the interpretation of the results through voting. I haven't seen anybody trying that, but I think many people would be surprised how well it works. :-)
You are making too many simplifying assumptions. One of these is that the decision-making process involves a simple up-or-down vote. That is rarely the case in complex discussions. Instead, as the number of folks who can bring up additional points for debate or an n+1th option grows, the length of time spent debating grows quadratically unless there is some procedure (For example, a presiding officer who can cut off debate) to stop it.
> I would say that is an issue in any project regardless how things are decided.
This is definitely incorrect. Decision procedures have a massive impact on how long things take to decide. I have empirically observed this. Student organizations at my university had a word for it: wanking. It was incredibly common at student group meetings.
What I meant was that the quadratic transaction costs apply to any large scale project anyway, because no one can fully understand it. In other words, I see the longer debate as a sign of project complexity, not choice of decision making process.
I agree that bad procedures can lead to indecision, but it's not different from indecisive leader really.
In fact, I think it would be bad to select this "leader" according to his expertise; he should rather be selected according to his ability to produce good consensus by incorporating those different inputs. However, we already have procedures (such as voting) that do that and that we can understand; why then bother selecting a person to do it in a black-box fashion?
In short, if you can reliably decide who is an expert, you can also reliably decide the issue itself. If nothing else than by following the expert in his opinion.
Presumably, if the leader is an expert in the field, that person should be able to recognize a good idea, even when it comes from somewhere else.
I am sorry, that's what he effectively does. The more other person is an expert, more likely is he to agree with the leader if he made the correct choice. You seem to think that good solutions are somehow unpopular but that's contradictory (unless there is somebody acting in bad faith). The best solution actually has the highest probability of being the popular one (otherwise the probabilities of the experts are incorrect).
> Presumably, if the leader is an expert in the field, that person should be able to recognize a good idea
This is exactly what I said. You say "presumably", but it is an assumption.
The point is, you don't actually need him. Everybody can voice their opinion about the best solution, and then they can have a vote. If you think it through, this procedure encompasses your proposal too, because your proposal is just a special case where they all follow (in the voting phase) the opinion of the person they agreed on. And the restriction that they need to agree on the person doesn't help you any.
But that aside, as I already explained, this is pretty easy to do with voting. All that's needed is that everybody (including the leader) voices their opinion. The people who feel that they are not qualified to make the decision can just vote for what the leader would vote for.
Maybe what you mean is that there is a person A who thinks that person B should get no vote, because they are not qualified enough (or perhaps that some other person C should get more votes, it's a similar deal). But this is already reflected in the "objective" probability of B making the correct decision. So either A's opinion agrees with the probability (through his own probability to make good judgement), in which case it doesn't matter. Or, it disagrees with the probability, and then following A's opinion can only make the result worse.
Seriously, the amount of basic misunderstanding of all things not programming related here on HN is starting to get to me. I can't read these threads without being compelled to correct such obvious errors. If you don't know what you're talking about, at least phrase it in a way so that it comes across as an opinion, or better yet, research before you type. It's ruining the quality of these threads.
I think it's simply because this approach is more prone to abuse. A good dictator leaves democracy in the dust in terms of efficiency, but converesly a bad dictator can make everything go to shit at moment's notice. In economy/politics, it's a matter of life and death. In open-source software, the risks of dictatorship don't matter - someone can always fork the project off and do it better, but even if not, no one is starving or dying because of it.
We could have elections and let elected experts to act unsupervised for a period of time, use liquid democracy (where you delegate your vote when you're not involved in a certain decision),...
"GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Over 12.4 million people use GitHub to build amazing things together."
I mean, it doesn't use the word 'technical' once!
Also, I agree that experts are not always right, but they are right in overwhelmingly more cases. Which is practically "always". The small number of times an expert is outright wrong, is a risk I'm willing to take.
I wasn't taking issue with the proposed decision making mechanism. I was taking issue with the idea that there are purely "technical solutions". In math, the most intangible of disciplines, I was taught that when working solving an open problem, the most important question to answer will always be, "So what?" It's easy to come up with novel but trivial proofs all day long. If you can't explain why the new proof is important, then, so what? Go play with Legos.
If such an intangible discipline requires some justification part of its most foundational task, then surely there must be some broader justification in software development. And I'm being specific when I use the term 'software development'. It's not like we're talking about computer science or applied mathematics.
Software development builds things that are to be used by end users for a purpose. There is plenty of room in software development for non-technical perspectives, and non-technical discussions will never be black-or-white. Often a software development project with be built specifically for a non-expert. In that case, to say that the end-user "should not necessarily be ignored" is such a bad tenor to be set for the discussion.
Last, I'd like to mention the idea of a do-ocracy, which is what many OSS projects have organically turned into. In these cases, the technical expert and the novice alike can do whatever they want, because folks will either choose to work with them or not. But in a do-ocracy it's not likely that someone will be forced to do something they don't agree with or at least sign-on-to.
If you want a "buck stops here" set-up, then go to a company that has a hierarchy or pay people to do what you tell them to do. But otherwise, there is no Utopia where programmers can go write whatever software they want and that others will be required to use without getting to share in the decision making process.