Except in more complex arrangements involving freelancers/contract workers the code that developers create obviously belongs to the company. When we talk about code ownership, we imply the knowledge to maintain that code. Code can be a very brittle thing and the developer who created it may be the only person who understands the background of why the code is the way it is.
I’ve been fortunate to have worked in many projects which took various approaches to code ownership. In fact I’ve witnessed both extremes of the spectrum and various points in between. The result? I’ve come to the inescapable conclusion that code ownership is not only a good thing overall, but that it really ought be an unalienable right for developers. I’m ordinarily open-minded and don’t consider myself a purist on most matters but this might be an exception.
The reason is simple, as in all things, when a person’s name is attached to a thing, more care will put into its making.
I’ve been developing professionally now for over 15 years. Long before movements like XP, TDD and Agile Development became buzzwords. These movements have introduced or at least popularized certain beneficial techniques but also some just plain bad ideas like backseat driving as a productivity booster and the topic of this post, code ownership or rather the movement against it. As I said above I’m generally not a purist so I prefer to handle each problem on a case-by-case basis and not handcuff myself with artificial restrictions.
I could write a treatise about how religiousness has taken over the profession of development but in this article I just want to discuss the rationale behind the movement against code ownership and why I think it misses the point. So without further ado…
The biggest crux of code ownership is that of flight risk. What if the owner of a piece of code quits and takes his knowledge with him? What if he uses his knowledge as leverage to force a raise/promotion out of us? What if this? What if that?
There are a lot of “what if?”s out there. These scenarios could indeed play out but one thing that isn’t a “what if?” is that less experienced developers are going to make bugs and continue making bugs until they learn to fix them.
To counteract this possibility of flight risk it was proposed that total ownership of code be abolished. In its place various approaches have arisen…
- 100% shared code. Everybody owns everything/nothing. If a bug is found anybody can fix it. If the code isn’t clean, anybody can go in and clean it etc… If anybody quits it shouldn’t impact the company at all, in theory. The only problem with this approach is it doesn’t work. Development is a complex endeavor and it’s simply not possible to know everything. It’s more often the care that developers will be fixing code they’ve never seen before let alone understand.
- Team ownership. A project’s code is owned by the team. If one member of the team quits the others will pull up the slack. While not perfect, this is a more balanced approach. You don’t need to know everything, just the projects in which you participated.
It’s true that developers can pull up stakes and leave a company at any time (they aren’t slaves). If he or she has all the knowledge about a piece of code then that will be lost. Or will it?
Assuming the code remains, if a compiler can understand it well enough to carry out the instructions within, certainly a developer with some time can do the same. I’ve often inherited such code with little to no documentation. It takes time but not all is lost.
Going in Reverse – Keeping Developers Around
All other factors being equal, the more a person’s name appears in code the less likely that person is to leave the company. Developers are builders and we take pride in the things we build. We indeed become attached to them. That attachment, if it’s a positive one at least, can very well anchor us down. And it’s a compounding effect!
80% of development is maintaining and extending existing code and the longer we work on a thing and the more code we own the harder it is to just leave it. By abolishing code ownership you are actually discouraging this attachment from occurring and are arguably giving little reason for developers to stick around.
You might ask “Isn’t the attachment to the delivered project enough?” The answer is “no”. Attachments aren’t binary, they’re degrees, and the more there are the better.
If you fear that your developers will up and leave at any time you may have the much larger problem of a crummy work environment. Any great place to work will inspire people to stay.
Code Ownership = Code Accountability
One of the best properties of code ownership is that it allows the code to develop the developer. If I make a mistake (it’s been known to happen) and I’m tasked with fixing it myself I’m going to learn from the mistake and the likelihood of me repeating it in the future will diminish if not drop to zero entirely.
Remember, bugs don’t come into existence by themselves, it is we developers who put them there in the first place. Of course we didn’t do it on purpose, they were put there as a consequence of us not understanding all the circumstances in which our code would run. It follows that one of the best ways to prevent bugs is to learn from them by fixing them.
The alternative, is to have somebody else fix my mistakes in which case I might not learn much if anything. Adding insult to injury, the developer who fixes my bug has now been burdened by me and with each such occurrence will hold me in lower and lower esteem.
Personally, I would prefer to be held accountable for my successes and my mistakes.
Fixing other People’s Code
Ask any developer if he or she enjoys fixing other people’s code. I guarantee you that you’ll be given a resounding “NO”. I hate it too. It often feels unfair.
Over my many years of developing I’ve settled upon patterns that have proven themselves capable of creating robust code. I’m not perfect of course but I don’t leave a mess everywhere for others to clean up. I see it as an issue of discipline and I just don’t want to be a dick to others.
The fact is, in the same sense that you can’t become a programmer simply by reading a programming book you can’t learn from your mistakes if somebody fixes them for you and just tells you where you went wrong. You have to fix bugs to learn how to prevent them. I’ve fixed my share and I’m a better developer because of it.
My most robust code is in my personal projects. If it wasn’t I’d be inundated with bug reports, which I cannot afford to deal with. I own not only the knowledge but the very code itself. Unless I open source all my code nobody will fix my mistakes for me so that code has to be the best.
Each developer is of course different but I suspect those who truly care about quality share the same experiences as myself in this regard.
Even developers who work in an environment where code ownership is considered evil should at least pursue their own personal projects during their off time and see for themselves which approach works best.
It might just give us cause to rethink code ownership.