Archive for the ‘Software Engineering’ Category

Effects of Ownership in Software Engineering

September 18, 2011 11 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!