Home > Psychology of Engineering, Software Engineering > Effects of Ownership in Software Engineering

Effects of Ownership in Software Engineering

September 18, 2011 Leave a comment Go to comments

What do you own? A home? Car? Quad-core computer? No matter what it is, you’ll probably agree with the statement:

“When you own something, you treat it differently.”

It’s a simple concept, but one that I believe is incredibly important and under-appreciated, especially in software engineering.

Depending on your personality and what “it” is, ownership might mean you put more OR less effort into upkeep. If it’s 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 pick up after yourself a little more. On the other hand, you might always schedule regular oil changes for your vehicle, because you could very well have it for the next decade if you don’t get that raise. With rental cars, why not “gun it” to get the RPMs up to 6K? After all, you’re not going to be held accountable for the early engine problems.

Clearly ownership affects human behavior in a number of ways, both positive and negative. And ownership is not a binary state. There are a range of possibilities, each having a unique effect on a person. You might own it, your family, your friend, or a rental company. Further complicating things, accountability and visibility matter. If others can easily prove misuse or negligence and hold you accountable for it, through fees, public humiliation, or otherwise, and if you’re aware of that possibility, you will modify your behavior accordingly.

The matter of ownership and its effects on human behavior are very 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 label as “proactive owners”. If John B. Coder authored a particular module and someone observes a bug in it, John takes notice, cares, and sees to it that the issue is resolved. At the other end of the spectrum are engineers who default to a “not my problem” attitude.

I believe engineers should take ownership of their work and an engineering company’s culture, process, and management should encourage and facilitate ownership. Specifically,

  • Module authors should write tests for their modules and be responsible for fixing the tests when/if they start failing.
  • An author should expect to be the owner for the lifetime of the product. By knowing they will be responsible for the long term maintenance and support of their work, they will put more thought and effort into it up front. Naturally people have their own interests closest to heart. Through long term ownership, a company can ensure its engineers individual interests are most closely aligned to those of the company. Programmers will work hardest to prevent bugs when they know that they personally will have to deal with the customer problems if they occur.
  • Management should push for this complete ownership even at the expense of short term efficiency gains.
  • When hiring, prefer engineers that demonstrate ownership and a “buck stops here” attitude.
  • Some of these ownership concepts are discussed at my company from time to time. But I don’t believe it is implemented as fully as it should be. Everything can always use improvement!

    1. Mike Roberst
      September 19, 2011 at 2:30 AM

      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?

      • September 19, 2011 at 10:24 AM

        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.

    2. Johnicholas
      September 19, 2011 at 6:58 AM

      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?

      • September 19, 2011 at 10:28 AM

        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.

    3. VictorNicollet
      September 19, 2011 at 7:11 AM

      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) ?

      • September 19, 2011 at 10:33 AM

        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.

    4. Travis
      September 19, 2011 at 7:42 AM

      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.

      • September 19, 2011 at 10:40 AM

        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.

    5. Scott Brickey
      September 19, 2011 at 9:11 AM

      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.

      • September 19, 2011 at 10:44 AM

        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.

    6. September 20, 2011 at 9:19 AM

      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.

    1. No trackbacks yet.

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out /  Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )


    Connecting to %s

    %d bloggers like this: