The Mythical Man-Month and the Chinese Secret, Part I

In The Mythical Man-Month, Fred Brooks presented the Group Intercommunication Formula,

which represents the number of communication links that occur in a team of n people. Clearly this is a simplification, but it provides at least a basic model for the communication overhead in a team.

Adding the nth person to a team adds n-1 additional communication links to the team. At some point, adding new people to the team actually decreases the amount of work done because of the additional communication overhead added. Where is this point? Well, if w represents the amount of work that a person can do, and c represents the percentage of w that each communication link consumes, then this point is defined where

So, for example, if each person on a team spends 1% of their time communicating with each other person on the team, then the maximum number of people you can have on that team before adding more people reduces the amount of work done is about 50. If each communication link represents 5% of a person's time, then this number is about 5.

Think about that for a minute in an agile context. If agile processes place emphasis on interaction and collaboration, then agile teams must, by definition, be small. If proponents of agile processes don't seem to be able to point to any widely-known, successful agile projects, it's because there aren't any. They're so small that almost nobody ever knows about them.

For agile processes to work on larger projects, they need some sort of organizational framework to work within. In following posts, I'll look at how such organizational frameworks affect communication links, and what that means for larger projects that want to use agile processes.

The Relative Strengths of Programmers

Jeff Atwood made a recent post on Coding Horror titled "The Two Types of Programmers". The premise of his post is that there are two types of programmers: the 20% ("alpha" programmers); and the 80% ("vocational" programmers). His post is a response to a post by Ben Collins-Sussman titled "Version Control and 'the 80%'".

The argument that there are "alpha" programmers and "vocational" programmers isn't new. It's been made ever since I can remember. Only the variables use to discriminate between these two types changes. It could be whether you've built a machine from scratch at home, whether you've installed Linux on it, whether you contribute to open source projects, whether you're familiar with the flavour of the month technology, or even as basic as whether you use Internet Explorer or Firefox. Whatever the discriminators are, the argument is usually originated from the 20% camp in order to build a wall between themselves and the 80%.

In reality, you can't divide such a large and diverse community into only two groups based on just a few variables. You need a whole bunch of crisp and fuzzy delimiters to be able to define classifications of programmers, and even then, you'll end up with way more than two, and these probably won't be clearly defined. There will always be a significant number of those who don't fall into one of the well-defined classes. Any attempt to define classifications for programmers is a purely academic exercise, with no practical application.

Every programmer is different. In any organization, and on any project, any two programmers with the same job title and level will fulfill different roles on a team. On a well-managed team, each developer will, at least in part, contribute according to his or her relative strengths. Some programmers are excellent designers, some write the most clear and concise documentation. Some are great team motivators, some are adept at communicating with management. Some write the fastest code, some write the most bug-free code. The list goes on and on. There are many, many different skills that programmers possess, and no two programmers possess them in the same mix. How valuable a programmer is to a team is largely dependent upon which of those skills are important in the context of the particular project or organization.

There is some truth to the arguments made by Ben and Jeff. An excellent programmer isn't merely 10% more valuable to an organization than a so-so programmer. The difference is more like 10 times. We all know that one programmer who is better at nearly everything than any other programmer we know. It comes down to whether a particular programmer's strengths are relative strengths when compared to everyone else. For example, if one of a programmer's major strengths is writing documentation, but on a team of 10 programmers there are 4 other programmers who write better documentation, then it's not a relative strength. Within a team, understanding the relative strengths of the team members is an invaluable tool in performance assessment and growing the capabilities of the team. That's what good managers look at, and probably how you're being evaluated within your organization.

So, what are you, as a programmer, supposed to do? Start by defining yourself as a programmer, and your role in your organization. Identify what you're good at. Of those things you're good at, are you the best on your team, in your organization, or even in your industry? If you're not, then recognize that these aren't areas of relative strength for you. Maybe some of the things that you don't think you're good at are actually areas of relative strength for you. Assess the needs of your team or organization. Which of your strengths are most in need? In this area, it's helpful to talk with your management, to find out what's important to them, and to find out what they perceive as your relative strengths. Identify the gaps between the needs of your management and the strengths of your team, and determine whether you can develop relative strength in those areas. Complement the strengths of others on your team, and be a bridge in those areas between technical staff and management. Make sure that you have at least a few areas of relative strength, as a buffer against changing organizational needs. Finally, once you've identified your areas of relative strength, strive to be in the 99th percentile in those areas, not merely in the 80th percentile.

In the end, the argument about what defines an "alpha" programmer from a "vocational" programmer is a red herring, fuelled by certain insecurities of those who believe themselves to be in the 20%. Strength in only a couple of narrowly-defined categories doesn't necessarily make you stand out in your organization. Being a great Lisp programmer doesn't count for much if you work in a .NET shop. And your organization isn't going to migrate overnight just because you happen to be great at it. The truly invaluable developers are those who have relative strengths in many areas, including non-technical ones that allow them to contribute no matter what the particular project or organization.