Why Facebook Said No to Individual Code Ownership

Should tech companies stick with the practice of individual code ownership, where one engineer is responsible for his or her code throughout its usage? Facebook software engineer Pierre Raynaud-Richard explained why the process is not used at the social network in a post on its engineering blog. Raynaud-Richard explained the concept of individual code ownership: Many software development companies believe in and practice “individual code ownership.” This may not sound like such a fundamental principle, but it actually goes a long way toward defining how a software organization works. At first glance, individual code ownership appears to have some nice benefits: System components have clearly identified owners (or “experts”). The code is maintained and there is someone to fix bugs and collect and selectively implement feature requests. Owned code is often believed to be better written (as it’s maintained and refactored by experts), better quality (owners fix more bugs) and better supported and documented. Owned code is commonly assumed to provide better return on investment, as it is maintained, supported and used for a much longer period of time. As for Facebook, he wrote: At Facebook, we don’t believe in or practice individual code ownership -- pretty much the exact opposite. This can be a shift for many engineers joining Facebook with prior industry experience because: There is not just one designated expert to answer our questions, implement missing features or fix bugs. There is often no one to impose consistency, even at a granular level, within a single component. Code is likely to age faster. There is a lot more opportunity for people to bring up new frameworks or components (that often overlap and compete with existing ones) without providing adequate support and maintenance. Despite the benefits of individual code ownership, I believe that eschewing it is one of the most important choices Facebook ever made. Two key values of our engineering culture are our focus on impact and our commitment to growth, both as individuals and a company. Both are in deep contradiction with individual code ownership, at least as I know it from other companies. He went on to point out some of the pitfalls of individual code ownership, such as: The ideas of the expert are no longer challenged. The gap in knowledge and “expertise” only grows with time, and the title and position of “expert” can be used unfairly to win arguments. Innovation can be crippled, as new ideas are expected to come from the individuals who are least likely to generate truly new ideas (because they’re so deeply involved in and biased by the details of the current design and implementation), and these individuals are given implicit or explicit authority to dwarf disruptive ideas from the outside. The official role and recognition of "code experts" implicitly dampen and narrow the creative contribution of new engineers. It is easier and more natural for them to just follow the lead of the “experts” instead of diving in and forming their own opinions and ideas. Over time, this may result in a “lean back” syndrome, where people feel they should care only about their own narrow piece of the puzzle. The expert inexorably drifts from a creative owner to the comfort zone of expert caretaker. Knowledge of the code and how to use it becomes more important than new ideas to improve it or reinvent it. A belief in the value of stability leads to ignoring fundamental gaps in favor of fixing bugs or implementing minor enhancements to extend the code lifespan, while dwarfing real innovation. The expert is literally encouraged to create and think less and less in favor of just helping people with basics, answering questions and doing easy maintenance. As the expert becomes “indispensable,” he or she gets praised and treated well without having to take much risk. At a personal level, this comfort and security can often result in apathy, lack of personal growth, lower motivation and a fundamental lack of significant impact. Worst case, a person in this situation can end up thinking of himself or herself as someone who can only contribute as a deep and narrow expert, who will usually only change companies to go do something similar for a competitor (themselves thrilled to have stolen an “expert”). Even if they feel they need changes, letting go of the security and easy recognition of their area of expertise is a scary decision to make. He concluded: Individual code-ownership provides some attractive benefits at first glance: better designed, maintained and supported code, and longer life-span for components and services. Unfortunately, it does it at the cost of introducing rigid definition of roles, which can limit innovation and company and individual growth. In the next note (coming soon), we'll discuss how collective code ownership works, what kind of people and companies benefit from it most and how people coming from an individual code ownership culture can integrate and thrive in a culture of collective code ownership. Engineers: Which side of the debate are you on? Image courtesy of Shutterstock.

Social Pro Daily

Why Facebook Said No to Individual Code Ownership

Should tech companies stick with the practice of individual code ownership, where one engineer is responsible for his or her code throughout its usage? Facebook software engineer Pierre Raynaud-Richard explained why the process is not used at the social network in a post on its engineering blog.

David Cohen

About

Subscriptions

Events

Publications

WORK SMARTER - LEARN, GROW AND BE INSPIRED.

Subscribe today!

David Cohen