

Code Ownership – Who Should Own the Code?  - javinpaul
http://swreflections.blogspot.ca/2013/04/code-ownership-who-should-own-code.html

======
onemorepassword
This isn't about code ownership, this is about micro-management: a manager
that likes to know and control who works on what, because god forbid
programmers might do something Wrong(TM) or Inefficient(TM).

Collective code ownership doesn't exclude stewardship or experts working on
the code they are most qualified to work on. In a healthy team this comes
natural.

Assume these people are grown-ups, who can figure out for themselves that a
change X to code Y can best be made by Jim (the senior expert), but it may
also be helpful if Johnny (the talented junior) makes the change after which
Jim reviews it.

Any ownership model other than collective ownership takes these decisions out
of the hands of those most qualified to make them and shifts them to hierarchy
and regulations.

Management's job should be limited to addressing those that undermine the
team's functioning and remove them if necessary, not facilitating it by
imposing code ownership levels.

The Martin Fowler example the author links to speaks of "undisciplined
programming by a couple of developers" and "sub-par producers". Geez, guess
what the real problem is here?

~~~
wisty
So ... who makes the decisions?

Johnny wants to make a change. Jim says "no". Johnny's now pissed, because
Jim's broken code is causing him problems. Jim's pissed, because Johnny wants
to touch "his" code. And let's pretend, for a minute, that they aren't both
100% perfect employees (because I know the answer is - "they'll sort it out
sensibly" - we need rules for when common sense breaks down).

~~~
6d0debc071
I'm unsure if that needs to a project management issue rather than an HR issue
though. If the team's having problems with Jim's code and attitude such that
people keep having trouble working stuff out with him, then Jim can be sacked.

------
rachelbythebay
No one answer could possibly handle every situation. I've seen the "benevolent
dictator" thing work, and I've seen it fail. I've seen "core teams" where
everyone has equal commit privileges, and some of those produce good results,
but some don't.

Then there are hybrids, where you have a big company and stuff gets sliced up.
eng/foo is owned by one group, but eng/bar is owned by another. Then there's
hr/secret which is owned by a third group and isn't even readable outside of
that group. The trick is that someone in eng/bar can submit a patch to one of
the owners for eng/foo, and if that person cares to approve it, then it can be
applied.

Can this be abused? Sure. Get approval for your change and then modify it to
be evil before you check it in. If the systems in place aren't specific about
what approval means and the people have bad intentions (or maybe are just
clueless), then it's possible to make all kinds of disasters.

The better question is: who or what is going to make sure someone actually
owns something? Just having some code in your depot is no assurance that
anyone is taking care of it. You might not find out that it's broken until
long after the last developer has moved on to greener pastures.

------
Heliosmaster
Why does it assume that Collective Code Ownership = Anarchy?

It simply means that anybody CAN edit the code, not that everybody WILL DO
everything. After all it's a matter of common sense: If I don't understand
what's going on, I will not touch it (this address the slow delivery
drawback).

All the other points against Collective Code Ownership seem a little empty as
well: inconsistencies are not result of collective code ownership, but poor
organization. Agile Programming != Anarchy

------
josephlord
In a big project this can also apply at team level. E.g. Driver team,
middleware team, applications team or front end, back end and tools. The
bigger the project the more appropriate specialisation of knowledge will be
but it is best if direct communications are open between teams to resolve
issues.

------
ExpiredLink
The word 'ownership' should be replaced by 'responsibility' or even
'accountability'.

