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
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.
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.
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).
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.
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
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.
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?
We are developing an Automated code reviews for Ruby developers using Github, discover how you can become a better Ruby developer.