When you share something, aren’t you more careful about it? Wouldn’t you be ashamed of damaging a share good? If you would, you are ready for collective code ownership. Let’s put some context : Fishing Cactus is a small studio that not only makes games, but also advergames and medical serious games. With a small team of no more than 10 programmers and 3 projects running at the same time, there’s no places for an engine team, a tool team,… The flexibility of the team is really essential for managing day-to-day needs in projects.
Collective ownership can be defined as : Nobody owns a piece of code, no one is responsible alone of a piece of code. In other words, code I wrote yesterday could be changed by anyone today.
Motivation
The engine is driven by the projects. No team is working on the engine itself, it works on project that needs improvement of the engine. So anyone can start working on graphic stuff, and the next day on sound stuff. No one gets frustrated, everyone can work on part they are interested in! This increases the comfort and the pleasure of coding. It also provide challenges to programmers by allowing working on something they never did before.
Knowledge spreading
As each piece of code is developed and maintained by different persons, the risk of loosing the knowledge is lower. The code is always known by more than one person, the company is then immune to disappearing employees ( either voluntary or involuntary ). And a coder can learned from techniques he found in the code. It really improves the overall knowledge of the team
Weakest link or Quality?
You might think then “the code is as good as the worst employee”. It might be true, but I choose a code base of equal quality over a perfect graphic engine with a rotten streaming system. On the other hand, there’s no way you can hide a dirty piece of code. When guys are assigned a single module, they tend to “black box” the code behind interfaces. And inside, the code might dirty “as long as it works”1. With collective ownership, another coder will end up seeing, analyzing, criticizing the code. The process tends to increase the overall quality of the code.
Flexibility
As any programmer can work on anything, it’s easy to move people around projects. If needed for a demo, the entire studio can work on a project for a sprint2.
Self-organization
I’m always amazed how community tend to self organize. Even in such a small team, leaders are emerging. And the rest of the team tend to ask for their advice and/or thoughts about refactoring, improvements,… People tends to take this role in their preferred field. Those leaders have a deep knowledge of existing code and facilitate the access to other programmers
Direction
My role is to lead the team and direct the engine in the right direction. But ensuring we are not driving at 200km/h into a wall does not mean I should keep my programers in step. I only guide them, help them making the good choice. And if they made the wrong one, I help them figuring it out why. Aren’t we learning from our errors?3 I really think that anybody can bring a good idea, even with no experience in a given field. I really try to manage my team as a family, not as a soldier squad ( once again, it’s all about comfort and pleasure )
Conclusion
There surely are pitfalls in collective owernship4, but the experience we had so far is really good. And it really fits our company values. I’m pretty sure thought that it does not scale well. As our studio is growing I might talk about it in the future ;-)
1. If I was given 1$ each time I heard this, I’d be rich
2. Fishing Cactus uses Scrum-based methodology
3. And for me, it happens nearly each day!
4. Such as spending a night fixing nasty bugs that appear 1 day before gold ;-)