Development Process – Is Code Ownership a Code Smell?

This is something I've been thinking about ever since I read this answer in the controversial programming opinions thread:

Your job is to put yourself out of work.

When you're writing software for your employer, any software that you create is to be written in such a way that it can be picked up by any developer and understood with a minimal amount of effort. It is well designed, clearly and consistently written, formatted cleanly, documented where it needs to be, builds daily as expected, checked into the repository, and appropriately versioned.

If you get hit by a bus, laid off, fired, or walk off the job, your employer should be able to replace you on a moment's notice, and the next guy could step into your role, pick up your code and be up and running within a week tops. If he or she can't do that, then you've failed miserably.

Interestingly, I've found that having that goal has made me more valuable to my employers. The more I strive to be disposable, the more valuable I become to them.

And it has been discussed a bit in other questions, such as this one, but I wanted to bring it up again to discuss from a more point blank "it's a code smell!!" point of view – which hasn't really been covered in depth yet.

I've been a professional developer for ten years. I've had one job where the code was well written enough to be picked up relatively quickly by any decent new developer, but in most cases in industry, it seems that a very high level of ownership (both individual and team ownership) is the norm. Most code bases seem to lack the documentation, process, and "openness" that would allow a new developer to pick them up and get working with them quickly. There always seem to be lots of unwritten little tricks and hacks that only someone who knows the code base very well ("owns" it) would know about.

Of course, the obvious problem with this is: what if the person quits or "gets hit by a bus"? Or on a team level: what if the whole team gets food poisoning when they go out on their team lunch, and they all die? Would you be able to replace the team with a fresh set of new random developers relatively painlessly? – In several of my past jobs, I can't imagine that happening at all. The systems were so full of tricks and hacks that you "just have to know", that any new team you hire would take far longer than the profitable business cycle (eg, new stable releases) to get things going again. In short, I wouldn't be surprised if the product would have to be abandoned.

Obviously, losing an entire team at once would be very rare. But I think there is a more subtle and sinister thing in all this – which is the point which got me thinking to start this thread, as I haven't seen it discussed in these terms before. Basically: I think a high need for code ownership is very often an indicator of technical debt. If there is a lack of process, communication, good design, lots of little tricks and hacks in the system that you "just have to know", etc – it usually means that the system is getting into progressively deeper and deeper technical debt.

But the thing is – code ownership is often presented as a kind of "loyalty" to a project and company, as a positive form of "taking responsibility" for your work – so it's unpopular to outright condemn it. But at the same time, the technical debt side of the equation often means that the code base is getting progressively less open, and more difficult to work with. And especially as people move on and new developers have to take their place, the technical debt (ie maintenance) cost starts to soar.

So in a sense, I actually think that it would be a good thing for our profession if a high level of need for code ownership were openly seen as a job smell (in the popular programmer imagination). Instead of it being seen as "taking responsibility and pride" in the work, it should be seen more as "entrenching oneself and creating artificial job security via technical debt".

And I think the test (thought experiment) should basically be: what if the person (or indeed, the whole team) were to vanish off the face of the Earth tomorrow. Would this be a gigantic – possibly fatal – injury to the project, or would we be able to bring in new people, get them to read the doccos and help files and play around with the code for a few days – and then be back in business in a few weeks (and back to full productivity in a month or so)?