Aristotle on Code Ownership

For those that enjoy a little Ancient Greek philosophy, Paul Meany introduces Aristotle’s views on the ownership of private property in Aristotles defence of private property

This reminds me of the discussions on code ownership in the early days of agile; discussions that are regularly resurrected by each new generation of software developers.

When Jeff De Luca was creating Feature-Driven Development (FDD) towards the end of the last century (i.e. in ancient times but not quite as ancient as those of Aristotle), eXtreme Programming was arguing loudly and often belligerently for collective ownership of code.

FDD argued, however, for code ownership for reasons that are not dissimilar to Aristotle’s arguments for private property ownership:

  1. With code ownership, code owners have something that they can take pride in. They are more likely to be deeply concerned with the quality of the code they own ensuring it is cared for and not neglected because it reflects on them, their reputation and self-esteem; they “have an incentive to be productive with what they are uniquely responsible for since they will benefit directly from their own efforts. On the other hand, communally owned [code] does not produce the same incentives because the fruits of your efforts are not solely your own.”
  2. In addition, being more familiar with their code, they are able to more effectively maintain the conceptual integrity of the design and consistency of testing approach of that code, helping again to keep quality high.
  3. Having code owners helps resolve arguments about how to best to support new features. In collectively-owned code, different developers may hold different opinions about code design, sometimes passionately. With no clear arbitrator to make the call, the arguments can go on and on.  With code ownership, such decisions and the responsibility for them lies squarely with the code owner.

FDD talks primarily about class owners because in ye olde development, we wrote traditional object-oriented applications and the class was the obvious unit of encapsulation. In these more service-oriented days, the unit of encapsulation is more obviously, the component or micro-service.

Therefore, I believe component owners and component teams (or micro-service teams) are crucial in maintaining quality of software product and its source code.

At first glance, the idea of component teams seems to be at odds with FDD’s emphasis on the use of feature teams … but the difference is that FDD’s feature teams are virtual (we used to call them dynamic teams but virtual is the more usual term these days). In FDD feature teams work as follows:

  1. Feature teams are led by feature or product owners (originally called Chief Programmers, more technically-able than traditional Scrum Product Owners and often assisted by non-technical domain or subject matter experts)
  2. Early in the planning of a feature’s development, the product owner identifies the components that need to be enhanced or created to provide that feature.
  3. The owners of those components, or one or two members of each of the component teams that own those components, become the feature team for the delivery of that feature.
  4. This newly-formed feature team takes the feature through the development process until it is ‘done’; the definition of ‘done’ for each component has been met, all the usual minimal requirements are satisfied, and the feature its integrate into the overall product.
  5. The feature team disbands, and the process starts again.

Like all systems and approaches, this virtual, dynamic feature teams approach has advantages and disadvantages … but the biggest advantage is being able to build feature by feature across multiple components while retaining the quality benefits of code ownership.