I’m sick of Collective Code Ownership. I’m sick of it not because it’s a bad practice. It reduces knowledge specialization. Everybody knows the majority of the code base. The project won’t just fold if the chief architect left. But it has been misused as an umbrella for incompetent developers. To apply this practice, Agile teams usually share one source control account (this, of course, is also because of pair programming and swapping). But when a bug happens, it’s really nice to know who made the change. It’s not that we want to finger pointing. We just want to know the business and technical reasons behind the change. That’s why we leave our names in the comment when checking in at my current project. We didn’t enforce this at my previous project. Things didn’t go out of control because we only had 6 developers. After I left the project, the remaining lead developer suggested leaving names in the comment. The one developer who everybody knew made the most mistakes totally freaked out. I guess that was enough to demonstrate how good an excuse CCO is for the incompetent ones.
Sometimes I do feel like finger pointing. Why? Because I’ve had enough! I don’t mean I’m perfect. I make mistakes too. But I don’t make mistakes EVERY SINGLE DAY! Most of my mistakes were made because I missed a test or I misunderstood the business requirement. Not because I wrote crap code! But thanks to Collective Code Ownership, people who can’t stand dumping more crap on an already pretty high pile of crap ended up cleaning up somebody else’s mess. It’s good for the project, I guess. It’s definitely not good for the mental health of the cleaners. So if you find I’ve gone psycho in a couple of weeks, this post explains why.
Sounds like somebody needs a vaaaacaaation! I admit I hate crappy code, but perhaps my favorite thing in the world (after beer, golf, and babes) is refactoring that code. It can be almost therapeutic, and nothing beats taking a tangled mess of junk and turning it into a thing of pure awesomeness.
In theory pair programming should act as a form of real time code review, so people really should not find it easy to hide their incompetence. On the other hand, if that isn’t enough, then I can think of only two solutions. The first is to do some chalk talks in which you highlight problems you’ve seen in the code and address how best to avoid them. You can also offer to pair with anyone who wants help. Hopefully that’s enough because the second solution is much more extreme: If some people are really not able to write code that’s up to par, even after you’ve really tried to help them, then fire them. Maybe I have too much faith in people, but I like to believe that if you help people to learn better ways of doing things, they’ll catch on and improve.
I have to admit that there are areas of PAS where I found myself wondering how so much code was written without anyone really hunkering down and thinking about what needed to be done. Instead there’s this mess of kludges that barely holds together, and if you try to fix one part, then something else that was written to balance the first kludge breaks, and so on.
It sounds like there has been a misunderstanding somewhere. Collective Code Ownership doesn’t say you should all share the same account for the source code control system.
It says we share ownership of the code and anyone can make a change where ever they think they need it.
Cheers Mark Levison