Sunday, November 18, 2012

Design consensus - the Apache way

The ways to lead the team

There are basically two extreme ways of leading the team of software engineers.

  • Supervision. You control people in your team. You tell them what to do. You make a decisions for them, which you order to execute.
  • Democracy. You are equal to the others engineers in your team. Your voice in design and architectural issues is equal to the voices of the others in the team.

As we well know, the bad team leads supervise their team. Good team leads serve their team and help them to perform.

The flaws of democracy

Let's face it - democracy is not always the best option.

Democracy in a team is good as long as all the team members are equally motivated, experienced and mature software professionals.

And what about new team members? They don't know the culture of your team yet. They need time to learn how people in the team works and what are the standards within in.

What about the responsibility? Your team works for somebody. Who should take the responsibility in the front of the business holder in the case of the failure? Who approves the critical decisions and takes responsibility for them?

The Apache way to lead the team

In Apache, all design decisions are based on the consensus between team members (committers). Voices of the project leaders (PMCs) are stronger than votes of regular committers.

However PMCs don't give the orders to the committers. They work with the committers on regular basis instead.  But in the case of design or architectural disagreement, PMCs are the ones who decide.

In order to become a committer, you need to work with the project team as a contributor. While being a one, you got no decision voice in the discussion. The is the time you learn the project and the way the Apache works.

I like to think of the good team as of the little Apache project. With a tech lead being the PMC, regular team members being the committers and team newcomers being the contributors.


  1. "Democracy in a team is good as long as all the team members are equally motivated, experienced and mature software professionals."

    In my software experience, Democracy has failed because a lot of people lack design wisdom. There are a lot of people who aren't equipped to make architectural decisions.

    I do not argue that such people are useless. On the contrary, some of these people are very skilled in implementing algorithms, methods, and classes; they simply do not know how to design the classes they create: they don't know which methods belong in a given class; they don't know how to break large abstractions into two or more intermediate abstractions.

    I do believe that the role of architect is very necessary. I hope you are in agreement.

    Jon Savell

  2. Yeah, definitely Tech Lead (PMC) need to have the big picture of the project constantly in mind. The other members of the team not necessarily.

    Similar situation can be observed in the context of build maintenance. Some people just hate to deal with all the Maven and CI stuff. Again - tech lead need to feel comfortable with these issues to keep the project sane in the long run.