Effects of Ownership in Software Engineering
When you own something, you treat it differently.
It’s a simple concept, but one that I believe is incredibly important and under-appreciated in software engineering.
Depending on your personality and what “it” is, ownership might mean you put more or less effort into upkeep. If “it” is your car and you don’t mind a bit of trash here and there, you might let it go, but if it was a friend’s car maybe you’d be more proactive about picking up after yourself. If you know you plan to own your car for years to come, you may choose to keep on top of maintenance so that you have fewer issues down the road.
Clearly ownership affects human behavior in a number of ways, both positive and negative. Ownership is not a binary. There are a range of possibilities, each having a unique effect on the person. Accountability and visibility also matter. If an individual’s actions are visible to the team, the person may modify their behavior accordingly. The team as a whole has ownership of their project and should maintain discipline in how the software evolves.
The matter of ownership and its effects on human behavior are quite evident in software engineering. In this context, I’m talking about ownership of both lines of code and the resulting products. Many of the best engineers I’ve worked with I would describe as “proactive owners”. On the other end of the spectrum are folks with a “not my problem” attitude.
Consider how ownership should factor into the work your team does. Potentially the team taking ownership of their work, collectively, is most important. But for that to work the individuals on the team have to step up as well.
If the team is to be responsible for the long term maintenance and support of the product they build, and are conscious of that, they will be more inclined to invest thought and effort throughout the project.
It’s motivating to know that, when a bug arises with a customer, that you’re going to be the one that has to deal with the problem. End-to-end ownership may have a dramatic effect on the overall results that your team can achieve.
When hiring, consider whether you should be looking for candidates that demonstrate taking ownership in their past work.
Some of these ownership concepts are discussed at my company from time to time, but I think we should consider them more frequently.
The Real Man-Month 
Things like: budget, schedule, and deliverables get chosen without regard to the person implementing the code. How can someone take ownership of something like that?
I would hope budget, schedule, and deliverables are all negotiated and signed-up for by your R&D team! You’re right that if a developer has no input on the matter, and is only assigned tasks, then the developer won’t be motivated and won’t really take ownership. But that’s why a company should work as a team with decision making flowing both down from the management AND up from the developers.
Keep in mind I work for a small company so it is relatively easy for decision making to flow both ways. In a larger company, I imagine a constant top-down decision making process would hurt the individual developer’s enthusiasm and personal investment in a project.
Two comments:
1. Have you experienced territoriality, an unpleasant kind of ownership, where an engineer is not willing to teach, explain, or allow anyone else to make modifications to “their” code?
2. You discuss psychological ownership – would you be an advocate of legal ownership, with engineers normally owning the code that they work on?
About 1. Actually, I haven’t had that experience in my professional career (maybe in college though). We’re all busy enough that if a non-owner wants to step up and take control of a situation, then by all means, go for it. Now, I suppose I’m guilty of an exception to what I just said, in that if I know someone isn’t capable of doing a good job when taking ownership of a problem, I will feel territorial and not like giving up control of my work.
About 2. Legal ownership would definitely be a motivator, but at first blush it seems to me like the net effect would be negative for the company. I’m not sure I’d want to work somewhere if would be held legally responsible for a bug I created. Everyone makes mistakes. Seems like it would add an unnecessary level of stress to the workplace.
In the context of ownership, how does the team handle the situation where the owner of a module leaves (or is fired, or is hit by a bus) ?
Good point. Like Scott Brickey mentions below, team ownership is more effective and valuable than individual ownership. At a MINIMUM you want at least one person to be somewhat responsible for a piece of code. At many companies, including mine, even that can be a struggle. That said, I would think you should always strive for team ownership by having quality documentation, easy to use APIs, and internal training courses to bring people into the know.
Do you propose that if I make modifications to a module that you “own”, that I can just say “He’s got it” when I break all the tests?
I agree that it’s important to take ownership in the work you produce, but how would you handle engineer turnover? If you create silos then a single bus that meets your engineer who owns module X, which just happens to be the core of your system, can cause you to lose great amounts of productivity to bring another engineer up to speed on the bus-meat’s code.
That scenario does happen, doesn’t it? I know from personal experience…
Clearly that is not ideal. One way to help prevent that is using a continuous build & test system, so that when a test fails on a particular module, anyone who has touched the code since the last successful test is notified that they might have broken it. Hence anyone that falls into that category is assigned some responsibility and should take some ownership of the problem.
About your second point, I did fail to address in my post that I believe team ownership is the ideal, not individual. The more important a module, the better its tests should be, the better its documentation should be, and the more the team has collective responsibility and ownership for that module to be working.
As a GROUP, sure, own a solution. As an individual (or where you are *the* developer), ownership just leads to silos of knowledge; developers feel that they have just created job security… companies may feel that they have a liability… and what happens when the silo of knowledge is on vacation and poop hits the fan? (answer: working vacation).
I 100% believe that even FEATURES should have multiple developers touching the code… it takes a little more time during development, but resolves many more problems than it creates. Usually I find the easiest way is not to implement pair programming, but simply to force bugs and new feature requests to be shared by the team.
You’re absolutely right, and that was perhaps the biggest omission in my post. Like you said, through teamwork you collectively should arrive at the best solution to a problem. Having multiple developers involved in the design and implementation process certainly has benefits. My company often fails in this respect because there’s always too much to do and we’re spread too thin, so more often than not features are added without enough input from multiple engineers.
I like the idea.
However your conclusion does not take into account that we work to live and not the reverse.
“I believe engineers should take ownership of their work”
“An author should expect to be the owner for the lifetime of the product.”
Why not ? If I am paid accordingly, I’ll do it.
Don’t get me wrong I like the idea of taking responsibility for his / her code, and I do it already to some extent but to do it like you wrote in your post opens the door to a lot of abuse and at the end it will just be a burden on the back of the engineer.
Besides an author is not the best person to really test a product.
I’d say an author is responsible of what he codes until the shipment has been decided, after that it’s another story.