Building on my previous article “The Branch Not Taken”, I’d like to convince you of the importance of code ownership. In Garret Hardin’s essay “Tragedy of the Commons”, he describes the burden that communal freedoms place upon a finite resource.
Protecting your release branch
If you consider stable, production ready code as a finite resource, it naturally follows that granting everyone write access will slowly, but surely, degrade its worth. So, in the interest of keeping your release branch in a pristine state, you’re going to have to remove write access to the release branch (or trunk) from your developers. Pretend you’re putting up a fence around your codebase. But it’s not just any fence, I’m talking about a six-foot high, chain-link fence with a locked gate.
Why chain-link? We don’t have any secrets from anybody. On the contrary, communication between all team members is essential so everyone should still have read access here. Additionally, we’ll want verbose notification emails about every commit on this branch to be distributed to the entire team.
Why locked? Locks keep honest people honest. And passwords keep slothful developers away from your production code base. Sure, you could go overboard and try to surround your code base with electrified, razor-wire fencing; a mature, automated test suite is by far the best way to protect it. But, honestly, who can instantly whip one of these up?
Enter the Committer
Congratulations! After removing write access to the release branch, you now have the keys to a write protected code repository. But I guess you’d like to commit some code into your release branch at least once in a while, right? I’d like to formally introduce you to one of the most important roles on your team, the “committer”.
The committer’s job is to own the release branch, your production code base. They are personally responsible for everything that happens there. The well-worn excuses like “the other guy …” or “I was told to release …” do not apply in production (certainly, your customers don’t want to hear them). Only by making the committers personally responsible do you signal your seriousness about quality to the entire team. With great power, comes greater responsibility and giving the committer sole write access to the release branch means they will be held accountable for their actions.
How to select a committer
But whom to choose for this crucial position? From a career path perspective, it’s probably going to be some of your most senior developers. Some? Yes, you definitely need more than one, when you factor in illnesses, vacations and plain bad luck. Do you have a senior developer involved in operations? Even better. These are your best owners, because they ultimately get stuck owning all the production issues anyways. It’s in their best interest to keep the code running and maintainable.
Committers are a proven concept
By the way, what we’re talking about here is nothing new. The Apache Software Foundation has been successfully harvesting committers for over a decade! Granted, open source development is probably far removed from your everyday work routine, but I’m only talking about an interim decision to stabilize your code base. And borrowing some ideas from a group of developers, who’ve by and large never once looked each other in the eye yet consistently release quality software, doesn’t sound like the craziest plan you’ve ever come with.
What’s the outcome?
Taking the first step of granting code ownership is huge and will undoubtedly cause sweeping changes in your ongoing development practices. Why? Because suddenly some of those grazers have now become herders. The peer pressure of their exertions and ideas will guide the entire development group. Once the team accepts this role (and even begins striving to achieve it), you will begin to see a positive pull in the direction of code quality instead of code quantity. While quality is certainly a nice by-product of ownership, even more important is the committment you’ve shown your team in achieving it.