We need collective code ownership and it sucks

Introduction

Now that we’ve been three instead of two for some months, we’re turning back into a real development team, instead of just individual programmers. It reminds me of my previous experiences in teamwork, both as a team leader and as a consultant.

This renewed team reality confronted me with a long forgotten – crucial – concept: the importance of collective ownership of the code – and how hard it is to master.

The Infinite Joys of Group Work

What we are typically trying to achieve as a development team is somewhat akin to working together on a large document. So – for a moment – let’s forget that we are programmers. Let’s go back to high school and college.

Does this sound familiar? Teacher assigns a random subject – assigns even more random classmates – and there you go -huffing and puffing to the final version. Most often, we just split the work into parts, let someone

Hands put over another, palms down.

Now got all those hands on a single keyboard (Photo credit: Wikipedia)

write the intro and conclusion afterwards and (when we had time) made a very quick style check to ensure some consistency.

So much for the easy part…

Now, imagine that your are writing chapter one. In the middle of it, I’ll come to write the second paragraph. Much worse, a third person needs to make some updates to the fifth paragraph (changing the meaning in a significant way).

If we want our document to still make sense afterwards, we should create a nice structure for the chapter, and the other reviewer and I need to take the time to understand your organization of the chapter. If we don’t do that properly, our reader will face a document with no internal structure, jumps of style or even contradictions.

We are not just sharing documents – we are updating sentences, lines, words even – written by someone else. And it would better still make sense in the end.

Collective Ownership: Why We Can’t Do Without It

Maybe we could just keep each person on its own chapter – or if I get back to my original point about programming, letting everyone keep to its own module.

Brahms - Hungarian Dances for Piano Four Hands...

Code is like Brahms : a piece for 4 (or more) hands (Photo credit: Piano Piano!)

That would be much simpler. It is also a quite sure way to hell. If you are the only one that ever worked on module blue, that creates a lot of constraints on the whole team:

  • Should this module becomes very important for the customer, we cannot allocate more resources to it
  • I have no way to see that my own module, green, could benefit a lot from yours, instead of duplicating much of the code (in my own way, of course).
  • The day you are off, on holiday, or just gone – people do change jobs, as strange as it can be – and a problem occurs, I’ll have to write a nice mail to the customer explaining to him that this will have to wait.

Of course, specialization is normal – and necessary. Someone can be more proficient in one aspect or the other, and logically, if you spent most of your time on a specific part of the software, you’ll probably be the most knowledgeable about it. Even in this case, it is very important to temper the expertise with some collective work.

We are now ready to face the next part of the problem : implementing collective ownership sucks.

The Infinite Pains of Collective Ownership

Let’s face it: your code is awkward. It is not that it does not do the job, or that it is woefully inefficient, it is just weird. I cannot explain it much more, but it is a fact. I would not have written it that way.

Of course, my code is as awkward to you as yours is to me. For the same reason that we do not write, or speak, or express our opinions the same way. Because, basically, we are different persons, and our usage of language (whether it is Java or Ruby, or English or French) is something where those differences are very visible (heck, we probably speak the way we think – unless it is the other way around).

Each time you start reading another person’s code, your initial reaction will probably be the same: it feels strange, foreign, awkward.

Working together on the same codebase means mixing each of our very personal strangeness.

The result can quickly become ugly.

Making it work

As usual, it is a delicate balance: We want team consistency (for all the reasons above), but without depriving us of each programmer own capabilities – and again, you cannot totally detach someone skill from the way he expresses it – especially speaking of code: the way we express ourselves in coding terms is a major part of our skill as programmers. There are different (and complementary) strategies to achieve this.

Get conventions

First thing to do : define the team conventions. This can go from application design (with a standard layout) to style (we put a space before and after the “=” sign).

Remember:

having consistency is an advantage in itself.

There is not always a clear reason to pick between two options, but picking will help all the same.

Whether this is done in a corporate, dictatorial (team leader) or collective way is of no big importance as such – as long as it is done.

Apply them

Every development team has conventions. I have some (“and if you do not like them, I have others”).

During the meeting where they were defined, everyone looked happy with them. Then came the gory part: having them applied. You can hope for everyone to take everything at heart and never forget them. Or – you do not live in “My Littte Pony-land” – and people forget. Heck, some of your co-workers just won’t bother. Most often, it means having a team member playing the policeman, which is funny for no one.

Finally if a convention is not followed (on a regular basis), it may actually be good news: maybe this one is not that important?

Code like me

Agent Smith

Coding with my team is easy. (Photo credit: Wikipedia)

I was once or twice in a situation where I had to work with several very junior developers. Something that did emerge was a very consistent style, which was actually mine (I did most of the initial work, so they started by updating my code, taking the convention along the way, almost unconsciously). While a decent temporary solution – managing business and a junior team is hard enough as is. It is not something I wanted to keep for too long. It basically downsized the team capacity to my own. Even being the senior, I was still just one person. I expected my team to outperform me, not to be a work extension of my capacities.

Work together

This looks like the best option on paper, and it actually is the best. It is also an endless circle of frustrations, misunderstandings and feeling of loss of time, mainly because of this “awkwardness”. Pair programming, or code reviews (if done together, not the “you send me code I send you back the proper way”) really help me, typically because they most often come down to:

  • I would not have done this that way
  • Okay, What other way would you have done it?
  • That way.
  • OK. Why would it be better?
  • (scratch his head)

This is actually a good exchange, because you arrive to the interesting point: exchanging ideas and ways to solve problems, which is the whole point of code review. But it will cost some hours of just… trying to get into the mind of the other. It sounds difficult, but it’s still much easier this way than by just reading the other’s code.

Loving what you hate

I’m convinced of the importance of collective ownership of the code base I contribute to. The only way to achieve it is to work together on it, passing responsibility among team members, avoiding “private zones” as much as possible. I’m also convinced it still sucks. But less than the alternative.

What are your ways and experience about sharing work and ownership with your colleagues? How do you achieve it? What are the biggest roadblocks?

Enhanced by Zemanta




6 thoughts on “We need collective code ownership and it sucks

  1. Kevin Peck

    As a team following code style standards is a big help. Why? Because if all code looks the same at least you get over the first “I hate this code because it is not formatted like mine!” problem. Every place I go has some rules, I just learn to follow them. Current place uses 2 spaces (not tabs) and { on separate line. Last place was 4 spaces and { on same line. While I have my personal preferences I don’t care about this and just follow the company line. If asked an opinion I will give one, if everything already set I just use it.

    At least when I open a file I know what to expect. That allows me to look at the code, the logic and not get distracted by the formatting. I think most developers are a bit OCD.

    Next you have other usage patterns. Does one developer only use Vectors when an ArrayList or HashMap would have worked better? That is a training issue. Do they not understand the singleton, factory or other patterns? More training.

    Can you understand their code? Can they explain it? Most of the time I am just happy they wrote it and I did not have to. But if they wrote it and there are lots of bugs being reported against it or it has major performance issues then we need to have a solid sit down look at it.

    Hopefully you hire people you can trust to sit down and write solid code. During the first 90 days you are going to need to verify that. Post 90 days a good open door policy where people are not afraid to bounce around ideas on a white board is what you want. Can’t have them sit in their cube and just code. You need to interact. You need to ask “Have you written something like this before? How did you write it? Do you have the code laying about? Are we already using a library that solves this need?”

    Reply
    1. Martin Post author

      Hi Kevin,
      First of all thanks for your insightful comment. I did take a look at your blog, really liked your “what programmers want” – reminds me of past experience trying to get a budget to get developers a second screen each. Did not end that well.

      Regarding the code style, I tend to agree with you : what is important is having one, whatever it can be (under some limits). As we said in the team this morning : I see no specific value in respecting styles… But I see problems not doing so (it helps recognising the code and concentrating on the real issue).

      You are emphasising the importance of the discussion, the exchange, in order to make the team progress and become more standardised. I like the collective / Darwinist approach : let have everyone argue his point of view, and trust the team to pick the right solution.

      Thanks for your visit, I’ll certainly follow you back.

      Martin

      Reply
  2. Pingback: Git: Who cares about branches? It’s all about collaboration and code reviews | 8th color

  3. Vladimir

    It is a pleasure to read that other teams encounter the same difficulties when working together.
    My experience of working in teams can mostly be summarized in:

    - there is always impedance towards getting familiar with modules that someone else wrote. People want to care only about their module and code it “the way they want”.
    - people always argue that the coding style should look like if the coding style they use when coding alone. When it is only a matter of taste – they would still want the code to look according to their personal preference.
    - in teams larger than 2, there is usually a need for a team member to play a “code policeman” for mates who don’t bother about following the conventions, writing tests or optimizing code.

    Reply
  4. Martin Post author

    Hello again Vladimir,
    My personal take on this is that -every- team experience this kind of difficulties, some are simply more conscious of it than others. I sort of agree with your three “problems”, I can just share the kind of “solution” I’ve (seen) put in place to help solve them. I would be most interested on your experience on that.

    1. As a team leader and now as a “coach”, I push to have people switch modules on a regular basis, putting not the most efficient (wo)man on the job, but one that have no prior experience of the module (with the initial module author as coach or second line, of course). This is costly initially (people are less efficient on new code), but made progressively redundant, which is something very important to me to avoid being stuck. Most of the developers responded favourably to this, as long as they were given time and resources to “dig in”. I almost never experienced problem with “This is mine, don’t touch it attitude”. I may have been lucky in that regard.

    2. I actually agree. I think the way -I- code should be the norm for everyone. Fact is, I also know this is a very subjective view that everyone has, which means I’m ok to adapt. Most of all, I find using a different style than mine a lesser evil compared to having several different styles in the codebase (see “Style Matters” article).

    3. This is something I try to avoid as much as possible. The best way is to discuss the style together (or pick the industry standard, like the Ruby Style Guide), then let a tool check it. It depersonalize the issue, and the tool never miss a problem. There are several of this kind of tool for different languages.

    What are your ways of dealing with this kind of problems?

    Martin

    Reply
  5. Pingback: Duplication is a rampant disease | 8th color

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>