Programmer Musings

LCDC: Developer Specialization

In The Myth of Code Anyone Can Read, I introduced the idea that least common denominator code (LCDC) is not a good approach to writing software. Among other things, this approach ignores programmer specialization that happens in any team of more than two developers.

Mental Caching

As a project becomes larger than one person can comfortably keep in their head, maintenance becomes more difficult. A developer has to spend some time re-familiarizing themselves with part of the code before they can do any serious work on it.

Depending on how recently they looked at the code, the developer could take almost no time or several hours re-learning the important parts of the code. (If you think the latter is unreasonable, I've been in code bases where we worked on a bug in code that had not been touched in almost 10 years. It takes a while to get up to speed on that.)

Since most programmers don't want to waste time, they tend to specialize somewhat in the code that they work on. This means that anything in that part of the code they can work on without spending a lot of time remembering or re-learning the code. This happens naturally. After finishing working on a bug or feature in the foo subsystem, they look for another bug or feature in the same system. After all, they are already familiar with it.

As this continues, that developer becomes the fastest person to work on that subsystem, and so bugs and features in that area tend to go to them, naturally.

The Specialist

When you think of development specialists, you probably normally think of someone like a database or UI developer. But, other specializations tend to happen pretty naturally. Watch who works on bugs in which area. See who people ask when they need to work in an area they don't know. Does everyone defer to Nancy on network issues? Is Fred the expert on the logging system? Do we put off working on the reporting framework when Robert is on vacation?

These people have become specialists. They are normally most effective in their area of specialization. Some may still be pretty good in other areas.

Effects of Specialization

As someone becomes more and more familiar with one area of the code, they tend to develop short-cuts and patterns that reduce potential bugs and make the developer more efficient. They may develop a specific metaphor that only applies to this part of the code. They develop jargon terms that supply a lot of context when they see them in the code. These are part of what makes them effective.

Forcing the specialist to write code in a way that everyone can understand would severely limit their effectiveness. They would have no shortcuts to remind them of the patterns they have seen in code. Instead of the code becoming tighter and more focused, it would tend to be more unfocused.

You might think I'm being overly pessimistic here. But, I have actually seen this happen. When a new person takes over the code when a specialist leaves (or is promoted), they tend to undo all of the specializations that they don't understand. The code normally slows down and develops new bugs.

This points to one of the major problems with having specialists. They reduce the project's Bus factor. This problem is relatively easy to solve. Have at least one other developer work with your specialist some of the time in their code to learn the context before it is critical. The second developer does not need to become as much of an expert in that part of the code, but they should be able to understand the thinking that went into it.

Summary

If you have more than one developer on your team, specialization is pretty much inevitable. In general, that is a good thing. Deeper knowledge in a particular area is likely to produce serious benefits over the life of the project. Along with that deeper knowledge will come patterns and idioms that are very specific to the target code. Mandating these patterns and idioms away will destroy the benefits of having a specialist.

In the next post, I'll discuss a kind of specialization that is critical to your project and you can't mandate away.