Do you own your code?

March 8, 2006 by Artem

When there are more, than one programmer on the project, the work has to be divided somehow. Agile methodologies propose self-organized team to decide who is doing what, more traditional waterfall approaches propose that manager allocates tasks to the guys with the free time slots. Whatever the method is, there is one more thing to consider: who is allowed to make changes where.
It is quite often that particular modules are "owned" by particular people and only they are allowed to make reasonable changes there. Usual argument is "The person, who doesn't know the module, can unintentionally break it".

What is interesting is why is it easily possible to the fellow programmer to break the code easily. After all he is often as experienced as the author of the code. The sad answer could be that the code is hardly understandable, too complex, not well commented or doesn't have enough unit tests to prevent the regression. Most of agile development methods promote: 1) fixing, testing and finishing the existing code, before adding new features; 2) test-driven development; 3) common code ownership; 4) frequent peer code reviews. The first two items help to cope with the "can unintentionally break it" part of the argument, the last two - with the "the person who doesn't know the code"

Next time you will hear that somebody should have an "own" module, ask the speaker for the reasons and tell about the known cures for the "code ownership syndrome".

P.S.
Thanks to the F-Secure person (sorry, still don't know his name) who shared with me the arguments presented in the post

Permalink