Weeks ago, some people in the Ubuntu community got a bit disappointed with the distribution’s core team:

> We are supposed to be a community, we all use Ubuntu and contribute
> to it, and we deserve some respect regarding these kind of decisions.
> We all make Ubuntu together, or is it a big lie?

We all make Ubuntu, but we do not all make all of it. In other words, we
delegate well. We have a kernel team, and they make kernel decisions.
You don’t get to make kernel decisions unless you’re in that kernel
team. You can file bugs and comment, and engage, but you don’t get to
second-guess their decisions. We have a security team. They get to make decisions about security. You don’t get to see a lot of what they see unless you’re on that team. We have processes to help make sure we’re
doing a good job of delegation, but being an open community is not the
same as saying everybody has a say in everything.

This is a difference between Ubuntu and several other community distributions. It may feel less democratic, but it’s more meritocratic,
and most importantly it means (a) we should have the best people making any given decision, and (b) it’s worth investing your time to become the best person to make certain decisions, because you should have that competence recognised and rewarded with the freedom to make hard decisions and not get second-guessed all the time.

[…]

> If you want to tell us that we are all part of it, we want information,
> and we want our opinion to be decisive.

No. This is not a democracy. Good feedback, good data, are welcome. But
we are not voting on design decisions.

Source: Ubuntu’s Issue Tracker

The dialogue above is about a UI change, not software design itself, but I see this happening all the time in software development projects, especially those following agile practices.

Agile is all about collaboration. In an ideal agile project, the team works together for the full lifecycle of a feature; everyone should understand and have input in what features are going to be prioritised, how the architecture is going to be like, etc.

That does not mean, though, that this is a democratic process. Someone in charge of designing a component should listen to her team and work with them to solve the issues pointed out, but she is still the one that will make the final call on how the design for that piece is going to be like.

There are two main problems in having a democratic design process:

• Mediocrity Always Wins: Not everyone in a team has the right skill set and experience to design every piece of the system. In a democratic design process you will end up with “The Homer”.
• Design by committee: “The defining characteristics of ‘design by committee’ are needless complexity, internal inconsistency, logical flaws, banality, and the lack of a unifying vision.”

That doesn’t mean that there is an Architect (capital A, please), designing the system for the less-skilled developers to write. Architecture is an ongoing thing; team members make architecture decisions every day.

What that means is that, every time a design decision has to be made, the decision must come from an individual or very small group of people that have the skills and experience required –excluding coaching and teaching, of course.

And this is pretty much the only way that this industry knows to produce quality software –or humankind knows how to produce any creative work, really. The best software were architected by a single person or a tiny group of individuals sharing a common vision and with similar skill levels (e.g. EJB vs. Hibernate, SOAP/WS-* vs. REST, C++/Java vs. Ruby/Python…).

Agile methods don’t change this rule. When it comes to design, meritocracy is still best.