Meritocracy

Table of Contents

Prev: Refactoring

I’ve noticed a pattern in software development that very frequently there is a perception that code is code: if you hire somebody that has written code before, then they should be able to write code for you. It strikes me as being reasonably similar to hiring somebody that speaks English for a job that requires speaking English. Both a newscaster and a teacher talk as a primary part of their job, but they are certainly not interchangeable.

The same is true in software development. All tasks have a domain knowledge component. Sometimes it is large and sometimes it is small. The larger it is, the larger the risk of problems if someone without the requisite domain knowledge is assigned tasks in that domain.

The biggest risk associated with changes made by somebody who is not a domain expert is that most domains have aspects which are counterintuitive. Code that looks “obviously” wrong can be completely correct and conversely code that seems right can be completely wrong. Changes to that code may seem to work because they pass the test suite.

It is often useful to look at an extreme version of an issue to discover a robust solution. In this case, an extreme example would be a code base that is maintained by volunteers and that anybody in the world is welcome to volunteer for. The volunteers may or may not provide a resume, they may use a pseudonym, and you might only know them via e-mail. How can you operate in such a situation? This example should sound familiar. It is the Open Source Software (OSS) development model as practiced by OSS development projects such as Apache.

Apache handles this problem via a system that they characterize as a “meritocracy.” Basically, you start out with read-only access to the system. You can propose changes via patches, and if you propose a change which is approved, your credibility increases in the area that you contributed. Over time, you can earn write access to more and more of the system and can eventually become one of the people doing the approvals.

Meritocracy allows developers to contribute outside of their traditional areas, to build trust in their capabilities, and to allow them to naturally gravitate to the areas where they are the most effective.

An efficient way to implement meritocracy is to allow developers to create branches where they can implement their ideas. If they are successful in implementing their idea and the result is accepted, it is then a simple matter to incorporate the change into the development process.

This is currently the last page of the on-line version of the book.

Please visit the Table of Contents to find more topics of interest.