Collective Code Ownership and Craftsmanship

April 16th 2010

Agile methodologies hinge on a model of collective code ownership - basically, the idea is:

I may work on module A this iteration and you on module B, but next iteration I may work on B and you on C.

No developer has sole responsibility for any piece of the system, we all own it together. If I need to update some piece of the system to implement my assigned user story, I can do it, with the caveat that unit tests should pass and probably some quality check should be met (e.g. peer review, etc.).

In any non-trivially sized team, this is probably a necessity; the alternative model, strict ownership of code, will just yield unnecessary gridlock, turf-wars, and code ghettos as developers operate unchecked in their own silo, hording knowledge, and protecting the sanctity of their individual assets at the expense of the overall architecture.

And even knowing this, that individual code ownership isn't really feasible in an organization, I still think that when we accept the model of collective ownership, something important is lost: craftsmanship.

Sure, Agile advocates would argue that pride of ownership just extends to the work of the team rather than just that of the individual. To some degree this does exist, but it's not the same. When we have ownership of something, whether a design document, an API, or a UI screen, it's our reputation on the line, our creativity and execution that make it a success or failure. We make decisions on our own, quickly, without having to reach team consensus, for good or for ill, accepting the consequences. And when it does succeed, we derive a strong satisfaction from knowing that someone found value in what we alone designed and created. We helped make something better, easier, faster. The freedom of owning our work is what makes programming fun...and meaningful.

Without ownership, this satisfaction is muffled. When people collectively own everything, no one owns anything in particular. Collective ownership often means collective design, and so there's less investment in the overall success, because, hey, these aren't necessarily my ideas, they're the group's. And because everyone's a stakeholder in all the code, decisions are often made via sophistry and compromise, producing an end design that often looks more like a piece of legislation and less like a piece of craftsmanship.

It reminds me of a favorite quote of mine from Steinbeck in East of Eden:

Our species is the only creative species, and it has only one creative instrument, the individual mind and spirit of man. Nothing was ever created by two men. There are no good collaborations, whether in music, in art, in poetry, in mathematics, in philosophy. Once the miracle of creation has taken place, the group can build and extend it, but the group never invents anything. The preciousness lies in the lonely mind of a man.

And now the forces marshaled around the concept of the group have declared a war of extermination on that preciousness, the mind of man. By disparagement, by starvation, by repressions, forced direction, and the stunning hammerblows of conditioning, the free, roving mind is being pursued, roped, blunted, drugged. It is a sad suicidal course our species seems to have taken.

And this what I believe: that the free, exploring mind of the individual human is the most valuable thing in the world. And this I would fight for: the freedom of the mind to take any direction it wishes, undirected. And this I must fight against: any idea, religion, or government which limits or destroys the individual. This is what I am and what I am about. I can understand why a system built on a pattern must try to destroy the free mind, for that is one thing which can by inspection destroy such a system. Surely I can understand this, and I hate it and I will fight against it to preserve the one thing that separates us from the uncreative beasts. If the glory can be killed, we are lost.

I know, to argue against collective ownership in the era of wikipedia, social media, and open source is probably insane. Working collaboratively obviously can produce high quality results, and benefit the collaborator as well.

Even still, talking to colleagues and friends that do software development on teams, I see this unsatisfied need to own. Just about every programmer has dreams about their own side project, where he makes the decisions, where he is responsible. It's this freedom which most of us need, and which produces works of craftsmanship.

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (1)
September 20, 2012
I often struggle with this topic.

The phrases "design by committee" and "group-think" are examples of how collaboration in certain situations can produce negative outcomes instead of positive. And any study of ancient Greek history will support the notion that realization of something magnificent does not come from any brainstorming session of a committee. Achieving something so innovative or revolutionary is beyond the capacity of most people to understand/see the value when weighed against the costs involved. A majority vote would normally rule against the innovator.

I've liked the idea shared by Fred Brooks in his book, The Mythical Man-Month, where he describes the ideal development team by drawing parallels to a surgery team in a hospital. There is one person calling the shots, the surgeon, and everyone else is in a support role, facilitating and supporting the surgeon as he performs his technical mastery.

But ... I also see first-hand the benefits of a collaborative, agile team: shared knowledge, self-organization, autonomy (within the team), healthy competition amongst team members.

Perhaps this isn't a question of one being better than the other. But rather one being better than the other in certain situations.