Who owns this?

I’ve been involved in software development for over a decade, and I can’t tell you how many times I’ve heard this question: Who owns this code? Generally, if someone has to ask, it’s already a bad sign, but the real bad sign is what comes next.  “Oh, Bob used to own it, but he left the company, and then it was Kumar, but he transferred over to the other team, now I guess Sue could probably answer questions about it,” but nobody owns it.

Well, that last part is seldom verbalized, but it’s on everyone’s mind.

We can talk all we want to about how software development is a team effort and how a problem should be solvable by anyone if the author did his or her job right, and if the code is perfectly designed and written that might even be true.  But not only is code rarely perfect, there’s something bigger at work here.  This isn’t about who should work on a problem, it’s about who is accountable for it.

Often, the original authors are the only people who truly embrace accountability for a piece of code.  They have a good understanding of the design tradeoffs, probably struggled through a few issues to get the code working the first time, and dealt with the first round of defects that were discovered.  If something came up in the code, they were not just willing but eager to address it.  It was theirs, after all.  If someone needed to understand something, they were able to explain it.  When asked the best way to change the code, they probably had an opinion.

But our artifacts usually outlast our assignments. People move around, code moves around, and the end result is that the people you’re asking to look into problems are rarely the people who originally felt responsible for them.

Are they going to refuse to take shortcuts to get this problem off their plate?  Are they going to try and understand the complex design and implementation decisions that brought the code to where it is?  Are they going to be able to make decisions around similar tradeoffs regarding the future direction of that code?

They should. They might not, but they should.  If you think about it, there are plenty of things you can do in setting the direction of your team to maximize your chances of this while the code is being written.  But in the end, it’s up to the new developers.

Embracing ownership of “someone else’s problem” is one sign of a true professional with pride in his or her work.  More and more it’s this feeling of accountability and ownership which I seek out and try to grow in team members, a trait whose presence I try to detect in job interviews.  It’s a core value which I try and reward publicly and encourage.  I’d rather an average coder with a true sense of ownership over a problem than a brilliant one who doesn’t care to look beyond the line of code which is causing a core dump.

So here’s a chance for a professional checkup.  Are you looking for ways to take ownership, or avoid it?  If you’re leading a team, how are you guiding your team towards this value?  If you’re at a more senior level in your organization, this extends way beyond “owning some code.”

How are you embracing accountability on a larger scale?


#1 Koder on 09.24.08 at 7:30 am

The problem, it’s when your boss don’t want to swap “owners” because they are efficient. Then, you stick forever on a old piece of code while others take shortcut to do some new stuff. Even if you’r professional and accountable , you get no reward!

New developers are often working on the last piece of code.

#2 Dave on 09.24.08 at 9:08 am

Part of working for a big company is that turnover is a fact of life, not just from people leaving the company but from moving around internally. I know it differs from project to project but on my current project it’s very rare that we have the luxury of making someone stay on a piece of code “forever.”

I’m sure the culture is different in other companies, and even business units within the same company. I know people who are still working on code they wrote 10 years ago, but I know many more people who are working on code they inherited.