The CodeNapper

After working on a code base for some time you are bound to start feeling more comfortable around certain areas. Especially if the code is expanding rather quickly. Often enough it is the areas you have created yourself that become the more familiar ones. You keep working on these areas, grab tasks that are related to them and as you do, you get more and more attached to them.

Before you know it. Yo consider this and that part of the code yours. As soon as someone mentions your areas you get an uneasy feeling, thinking to yourself. ‘What are they talking about. They better not be suggesting changes let alone actually doing any, on my module’. More and more often you feel that someone is threatening your little baby, you hold certain pieces dearer that other and without knowing it, you have become a CodeNapper.

It could be the other way around as well. Whenever someone asks if you or any other person could help with this or that you turn your head towards another person and say:

– ‘That is Bobs area.’

It is another symptom but the cause is the same.

How do one get out of this. Well, the way into this is certainly specialization. Work only on the same things today, as you did yesterday. Alone! Antidote: Collective code ownership. The way there is harder in practice than in theory. As with a lot of other things.

So, once again I would like to point your eyes to pair programming. It is useful in many ways but in this particular context its effect of spreading knowledge fast across a team is the one we are looking for. If two persons are pairing on a task today.

Tomorrow they both will have new partners and at least a third person knows about the area. Soon enough the whole team knows about the whole codebase. You will still have certain areas you have visited more that others. But not one single area should be unknown to you for very long.

If you have tried pair programming and do not like it or for any other reason cannot use it. Try rotating over different areas. Sort of trying to grab tasks that are not related to the one you just did.

If you routinely address or relay questions to the same person. It is probably time for more pair programming or responsibility changes. Chances are your bus number is alarmingly near one.


About Ola Ellnestam

Agile Coach, Systems developer, Agile Practitioner and father of three.

4 responses »

  1. Eivind Nordby says:

    Nice postings about important issues. Can someone also answer the following from experience? What is the price and payoff for this spread-out knowledge, and is it worth it? I don’t mean the price for working in pairs, I mean the price of having everybody know the whole product. It certainly must be more expensive than say two people knowing a certain area? How is the ROI for that spread-out knowledge?

  2. Miranda says:

    So true. This makes me a vigilant CodeNapper then! hahaha. My company left me to my own devices for too long (about 2 years), tasking me to make some technology work that people least understand. Well after many months of politics and criticisms, I finally got it working! Now they are seeing the benefits of it. However, a new manager came and believes there’s better way to make it. They went as far as spending 30K to purchase a tool for the sole purpose of RE-IMPLEMENTING my baby from scratch. I don’t really care about whether this threatens my job or not, but the thought that if they managed to re-create it, then I take it as a SEVERE INSULT to my efforts and that alone will make me leave my job for good. I cannot work with that level of disgrace. So I refused to participate in their efforts to create a “clone” of my baby using a different language, and just kept on producing results with it. Few months later they gave up and so we are still using my baby 🙂

  3. Ola Ellnestam says:


    One thing I have seen is that people /do/ want to specialize. For a whole lot of different reasons. Going against those forces creates a lot o friction in the organization.

    But, sooner or later someone wants to rid herself of duties and responsibilities. Usually because they want to quit. In these situations there is very seldom enough time to do a proper hand over. Thus, lots of knowledge and information goes lost.

    I’ve seen this happen a lot of times. Usually the organization recovers.

    I guess you want to some sort of risk assessment, from case to case. How likely is it that this information will be lost, due to a person leaving the organization. How much will it cost us in terms of resources, time etc.

    Blindly saying that everybody should know about everything is equally bad in my opinion.

  4. Ola Ellnestam says:


    Have you, or will you change your behavior after realizing this?

    Why or why not?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s