There is a new developer in our team. An agile methodology is in use at our company. But the developer has another experience: he considers that particular parts of the code must be assigned to particular developers. So if one developer had created a program procedure or module it would be considered normal that all changes of the procedure/module would be made by him only.

On the plus side, supposedly with the proposed approach we save common development time, because each developer knows his part of the code well and makes fixes fast. The downside is that developers don't know the system entirely.

Do you think the approach will work well for a medium size system (development of a social network site)?

I have worked in this manner and I always ended up having to change code that I didn't own. Since the code wasn't "mine" it always offended someone and the code was never documented or test'covered well enough for the changes to be easy. In projects I owned, I always encouraged group ownership together with rapid integration (to prevent long merges).
–
Danny VarodSep 13 '11 at 22:57

23

I cannot stress to you enough how bad of an idea this is. The answers below sum up everything wrong with code ownership so the only thing I can add is my personal experience how a software development shop I worked for turned from a great place to work with good people to a nightmare of egotistical developers, twice as many lazy developers, and terrible unmaintainable cowboy code.
–
maple_shaft♦Sep 13 '11 at 23:21

Sounds like he's trying to code himself into being irreplaceable.
–
Iain HolderSep 14 '11 at 8:38

4

A clarification: when you say "all changes of the procedure/module would be made by him only", do you mean nobody else is allowed to touch that module, or do you mean that when we're handing out tasks, we allocate tasks related to that module to the programmer that wrote it (or is familiar with it) first, if possible? That's a subtle difference, but it really changes the nature of the question.
–
Scott WhitlockSep 14 '11 at 12:17

13 Answers
13

It Depends

There is reason to believe that taking the position that every programmer should know every line of code is misguided.

If we assume for a moment that someone with a deep understanding of a piece of code will make changes 5 times faster than someone who doesn't know it at all (not a giant leap of faith in my experience) and it takes about a month of coding experience to get a really good understanding of a significantly sized module (also not unreasonable) then we can run some (completely bogus and fictitious) numbers:

Programmer A: has deep understanding

Programmer B: none

Lets say programmer A gets 1 unit of work done per day. In 4 weeks of 5 workdays he/she can get 20 units of work done.

So programmer B, starting at 0.2 units of work per day, and ending with 0.96 units of work on his/her 20th day (on the 21st day they're as good as programmer A), will accomplish 11.6 units of work in the same 20 day period. During that month programmer B achieved 58% efficiency compared with programmer A. However, you now have another programmer who knows that module as well as the first one.

Of course, on a decent sized project, you might have... 50 modules? So getting familiar with all of them takes you about 4 years, and that means the learning programmer is, on average, working at 58% efficiency compared to programmer A... hmmm.

So consider this scenario: same programmers, same project (A knows it all, and B knows none of it.) Lets say there are 250 working days in the year. Lets assume that the workload is randomly distributed over the 50 modules. If we split both programmers evenly, A and B both get 5 working days on each module. A can do 5 units of work on each module, but B only gets, according to my little Excel simulation, 1.4 units of work done on each module. Total (A + B) is 6.4 units of work per module. That's because B spends most of their time without any skill with the module they're working on.

In this situation, it's more optimal to have B focus on a smaller subset of modules. If B focuses on only 25 modules, they get 10 days on each, totalling 3.8 units of work on each. Programmer A could then spend 7 days each on the 25 modules that B isn't working on, and 3 days each working on the same ones as B. Total productivity ranges from 6.8 to 7 units per module, averaging 6.9, and that's significantly higher than the 6.4 units per module we got done when A and B spread the work evenly.

As we narrow the scope of modules that B works on, we get even more efficiency (up to a point).

Training

I would also argue that someone who doesn't know as much about a module will interrupt the person who does a lot more than someone with more experience. So these numbers above don't take into account that the more time B spends on code they don't understand, the more of A's time they take up by asking questions, and sometimes A having to help fix or troubleshoot what B did. Training someone up is a time consuming activity.

Optimal Solution

That's why I think the optimal solution has to be based on questions like:

How big is your team? Does it make sense to have everyone cross trained on every part, or if we have a 10 person team, can we just make sure each module is known by at least 3 people? (With 10 programmers and 50 modules, each programmer has to know 15 modules to get 3x coverage.)

How is your employee turnover? If you're turning over employees at an average of every 3 years, and it takes longer than that to really know every corner of the system, then they won't be around long enough for the training to pay itself back.

Do you really need an expert to diagnose a problem? A lot of people use the excuse, "what if that person goes on vacation", but I've been called in numerous times to diagnose a problem in a system that I've had no experience with. It might be true that the experienced person could find it a lot faster, but it doesn't mean you can't live without them for a week or two. Few software systems are so mission critical that the problem has to be diagnosed in 1 hour instead of 5 hours or the world will end. You have to weigh these risks.

That's why I think "it depends". You don't want to split 20 modules between two programmers right down the middle (10 each), because then you have no flexibility, but you also don't want to cross train 10 programmers on all 50 modules because you lose a lot of efficiency and you don't need that much redundancy.

Thank you very much for so detailed answer, Scott!
–
sergzachSep 14 '11 at 8:36

3

It's natural some people will come to know some parts better than others. But the concept of "ownership" implies that other people must not touch that code without permission, or that only the owner has final say, and that's going too far. Obviously yes, "it depends" if that's what they actually mean.
–
poolieSep 14 '11 at 9:25

@poolie - I agree but I don't know if it's that cut and dried. Does ownership really imply "must not touch"? I'm not convinced of that. I think it implies "this is the person with final authority" on that particular piece of code. There's more than one issue here... but I think the root of the question is about allocating tasks to programmers, not about disallowing certain programmers to work on certain code. Saying, "programmer B must not work on this code" is just silly.
–
Scott WhitlockSep 14 '11 at 12:09

I think ownership means highest priority to work with a fragment of code. If programmer A is free and he has highest pripority he should start to work with the fragment but programmer B shouldn't do this.
–
sergzachSep 14 '11 at 12:21

It's an awful idea. It may be quicker in the short term, but it encourages badly documented hard-to-understand code as only the coder who wrote it is responsible for maintaining it. When someone leaves the company or goes on holiday the whole plan becomes mucked up. It also makes it very hard to allocate workloads; what happens when two urgent bugs come up with the code one coder "owns"?

You should code as a team. People will naturally be allocated tasks and focus on certain areas but sharing workload and working together should be encouraged, not discouraged.

I agree in principle about working as a team, but in practice people seem to do better when they have a sense of ownership about their work, so long as it doesn't go so far as "you can't modify that code, it's mine!" That's why, while we do have team projects where I work, individual developers are responsible for completing assigned portions of the code.
–
Robert HarveySep 13 '11 at 22:47

1

One of the biggest problems of code ownership is serialization. What happens when 90% of the work all lies within one person's area? Is the rest of the team supposed to sit on its thumbs and wait?
–
Neal TibrewalaSep 14 '11 at 0:54

4

Where I work we have sections of code that are 'owned' by someone (or some group), but by no means are they the only ones that touch those files. There's simply too much code for everyone to know everything, so people specialize in certain subsystems and are responsible for know and being able to make larger scale design decisions on some system, but it's not uncommon for some else and make smaller quick changes as needed.
–
AlexSep 14 '11 at 1:23

3

@Robert Harvey: the team owns all the code.
–
Steven A. LoweSep 14 '11 at 2:39

2

"awful idea" is too strong. The Linux kernel uses that model and it seems it has worked well.
–
JohSep 14 '11 at 5:12

If it's general stuff (i.e. simple CRUD actions, etc), then I agree with Tom Squires (anyone should be able to work on it and edit it).

However...

If the solution in question requires domain expertise (lots of time has either been invested in the past or a lot of research needs to be done prior to implementation, as in this is something that you'd list in a job requirement as specialized knowledge that not everyone on the project has), then an owner should definitely be assigned to that part of the code. Having said that, anyone should be able to make modifications to it as needed, but they should always be reviewed by the person owning that area of the project.

You don't want to have your entire team (or a number of people on the team) researching and learning the same subject (wasted cycles). Assign an owner, but have them document their learnings and designs and maybe have them conduct informal (or formal, doesn't really matter) training sessions on the technology.

@Danny: I don't think that you thoroughly read the post. I did say that anyone should be able to make modifications to the code as long as it's reviewed by the owner. I also suggested that the domain expert should share their knowledge through formal or informal training sessions.
–
Demian BrechtSep 13 '11 at 22:54

+1 I think this is the only answer that indicates that different levels of ownership might have merits depending on the project.
–
Thomas LevineSep 14 '11 at 5:00

1

I don't really see this as ownership. Code reviews are natural (yes, natural), and it is just as natural that the most expert developer on a particular subsystem would review changes to this subsystem.
–
Matthieu M.Sep 14 '11 at 9:37

The advantage is that not everyone needs to research and understand everything. The disadvantage is that that makes each person necessary for their own area of code, and no-one else knows how to maintain it.

A compromise would be to have at least 2 owners for each area of code. Then someone can go on vacation, take a new job, or retire, and there is still someone who knows the code (and can train the new second person). Not everyone needs to learn everything, which is a bit more efficient.

Don't have the same 2 (or 3) people work together all the time. Switch out pairs for different areas, so the knowledge is also shared inadvertantely when working with a different person on a related program area.

This is a horrible idea. I have worked at a company that has used this approach and it is pretty much a recipe for heaps of technical debt. The bottom line is that two heads are almost always better than one. Why? Because unless you're an idiot, you know you're not a perfect programmer and you're not going to catch every mistake you make. This is why you need a team - more eyes looking at the same code from different perspectives.

It boils down to one thing: discipline. How many lone programmers do you know who are truly disciplined in their coding style? When you don't code with discipline, you take shortcuts (because you'll "fix it later") and the maintainability of the code suffers. We all know "later" never comes. Fact: It is harder to take shortcuts when you're immediately accountable to your peers in a team. Why? Because your decisions will be questioned and its always harder to justify shortcuts. End result? You produce better, more maintainable code that is also more robust.

Yes, it is slightly more efficient, in the short-term. And there ends the benefits. That doesn't even come close to outweighing the cost.

What happens when he's on holiday, or unexpectedly sick, or leaves, or gets hit by the proverbial bus? What happens when you want to flex resources to get one job through quicker than another? How effective can code-reviews be? How can a manager, particularly one who isn't in the code-base, know if the developer is working hard or pulling the wool over his eyes? Who will notice if the technical debt starts running up?

In my experience, people who like working this way are glory-hunters at best, lazy at worst. They like to be the only person you can go to with a given problem and they like their code to remain private. And they often like to code fast, without regard for readability.

That's not to say that, on a team of 50 developers, everyone should know all the code, but a team of 5-7 should own a module big enough to keep those people working. No individual should own anything.

I'd say it depends on the size and scope of the code base. Once you hit couple of hundreds of millions of line, you are definitely outside the "a single human can have everything in its head" domain and you will have to start having primary responsibilities divided.
–
VatineSep 11 '12 at 10:40

1

@Vatine: Right. So you break your code into modules and have a team working on each module. You still don't have a piece of code owned by one person.
–
pdrSep 11 '12 at 11:19

Yes, breaking it down to single individuals (probably) doesn't make sense, but there's certainly some arguments for "different ownership for different parts of the codebase".
–
VatineSep 11 '12 at 13:29

There are at least three issues that the other answers point out; but I'd like to try and treat both of them together. The two issues are:

expertise: Someone on the team has detailed knowledge about a particular field; this knowledge is independent of the specific implementation of that domain in the project

leadership: Although the work of building the project may be shared across many developers; the roadmap, as well as immediate decisions about important implementation details are in the hands of a particular team member or only a few members of the team.

egoless code: The particular way that the project is implemented is not dependent on the coding styles, practices or knowledge of any particular developer on the team; and by strict adherence to a well known coding style or a well mantained specification, any new team-member has an equal chance at understanding the hows and whys of the project as the experienced devs.

When the topic is purely one of expertise, the project's success may be dependent on a high level of knowledge about the domain; but it isn't dependent on a specific expert's knowledge of that domain. The experts, though perhaps rare and valuable, are still essentially interchangeable; one experienced tax accountant is as useful to a tax planning software project as another, from the point of view of their domain knowledge. The issue becomes one of how well the expert is able to transfer her knowledge to the project.

When the topic is purely one of leadership, the project's success is dependent mainly on the consistency and insight of the decisions made by the project leader; although we tend to favor project leads that have experience in the domain, or are proven as project leaders, this is sometimes secondary to the role. The "leader" could change from day to day if the decisions made are consistent from one case to the next and each decisions is swiftly executed by the team. If this is working right; many decisions don't have to be "made" by the project lead because the team already understands what decisions will be made.

I don't think the question was really about egoless code, but it's hard to talk about code ownership without also discussing how important this issue is. Maintaining a project is probably the larger part of the development cycle. The way to understand this issue is to wonder what would happen if some of the developers had to leave it immediately. What would happen if the whole team had to be replaced? If the project is cast in doubt because it depends on some key players, then you run a high risk of failure. Even if you never lose a single team member, the simple fact that one or a few developers are needed to advance the project means you might not be working as efficiently as you could if more developers were clued in.

Code ownership tends to prevent refactoring, create development bottlenecks and cause ego problems when code has issues that should be dealt with.

I do recommend consulting with code authors before changing, even though high standard code should be well enough documented, unit tested, integration tested and system tested to make this redundant, it still can't hurt to get another opinion.

This is bad for a lot of reasons, I worked in a shop where they tried to change from this to something more reasonable and it was ugly.

The reasons why this is bad:

If the code owner takes a vacation and some big bug pops up in their stuff, it will be very difficult and time consuming to try to learn the code AND fix the bug

If the code owner leaves the company, their projects will be severely set back since all the heritage and tribal knowledge just walked out the door

Documentation is poor. If I'm the only person to code in it, why would I document it? Related is the issue that any documentation that is forced to be created will also likely be poor because no one will know enough about the code to really say if the documentation is complete or even accurate.

Code holy wars can easily ignite when everyone has their own little sandbox, as others have mentioned this can get really stupid really quickly. Where this is a problem is when two people have to work together, neither is used to compromising ever on anything.

Because of the point above, the teamwork skills never form- people never have to work with others.

Fiefdoms can easily form, little kingdoms made from pockets of waste that don't buy the company anything. You don't know these are happening until it's too late because module or tool X is Bob's responsibility, and woe to thee who should even inquire as to what Bob is doing in his code.

Code reviews and peer reviews suffer since no one knows anything about the code. If you don't know the code, you can't spot the places that aren't right and are limited to commenting on text formatting and naming conventions alone.

And if you work for me... the company owns the code, not you. We have pride in what we do and what we accomplish, and in what we write, but it is a group thing, like when your team wins a difficult match. Any employee who works for the company owns the code equally, and in the course of doing their job is allowed to edit it in any way they please to do their job which is to forward the company's goals.

The biggest ones really are the personnel issues and the documentation. That person will leave some day, and boy will you be pushing schedule to the left for a few weeks.

The better approach is to have everyone be familiar with every part of the code base (or a half-dozen parts or so if it's really large and diverse) to the point that they can

Fix any defect in that area

Add minor or moderate new features or enhancements

Each person tends to know a little bit more about some things than others, so for the hard problems two or three can band together, or the defacto expert can take it on. I've worked in groups where this was the case and it worked out really nicely. Not only were there none of the cons listed above, the staffing was much more predictable since we weren't hunting around for experts.

The pro to sole code ownership is that the "code owner" can likely do things faster than others, but this only holds true if everyone is a "code owner" on non-overlapping projects. In other words, if people rotate around the advantage of the "sole code owner" goes away.

You're talking about a type of severe siloing that I don't advocate, and that I presume is rare. There's no problem at all to giving someone an assignment and letting him run with it, so long as he understands that he is still part of a team. That means he must follow the shop's programming standards and practices, and in general be kind to the person who must maintain his code after him. It means that the team must also understand how his code works and have complete access to it through the source control system, so that someone else can take over "ownership," if needed.
–
Robert HarveySep 14 '11 at 2:51

bus factor (also known as truck factor, or bus/truck number) is a measurement of the concentration of information in individual team members. The bus factor is the total number of key developers who would need to be incapacitated (as by getting hit by a bus/truck) to send the project into such disarray that it would not be able to proceed; the project would retain information (such as source code) with which no remaining team member is familiar. A high bus factor means that many developers would need to be removed before the project would necessarily fail.

"Getting hit by a bus" could take many different forms. This could be a person taking a new job, having a baby, changing their lifestyle or life status, or literally getting hit by a bus: the effect would be the same...

As with many things, it's a big "depends". If it's a strict "no one else can work on the code", it's probably verging on bad. If it is "the owner must do a code-review before accepting a change", it's middling to good, depending on how willing the owner is to accept external change.

The disadvantage is severe; the "truck number" of your team pretty much becomes 1.

To review, the "truck number" is defined simply as "how many members of the team, worst-case, could be hit by a truck before knowledge necessary to perform some critical task is lost to the team."

It is natural, and somewhat to be encouraged, for developers to focus on sub-disciplines; if everybody had to know everything having to do with the project, nothing would get done because everyone would be learning what everyone else had done, why it works and how it can be changed without breaking it. In addition, if devs are off doing different things to different areas it's less likely that changes will collide. So it's generally good to have two or three developers or dev pairs that work primarily in a particular subsystem of the project and know it well.

However, if only one person is ever supposed to touch a particular line of code, then when that guy quits, gets fired, goes on vacation, or ends up in the hospital, and that line of code is demonstrated as the cause of a bug that must be fixed, someone else has to go in and understand the code. If nobody else but the guy who wrote it has ever seen it, that will take time in order to get to a level of understanding that allows the developer to make the change that fixes the bug without making more. TDD can help, but only by telling the developer they made the "wrong" change; again, the developer must understand what tests are exercising which code in order to make sure that failing tests aren't trying to make the wrong assertions.

I don't take it to the extreme, but I prefer code responsibility. You write broken code, you should fix it. This can be done at the individual, pair, or team level. It prevents passing your mess off to someone else to clean up. This goes for changes as well.

Workload and scheduling issues will overwrite this. It would be foolish to hold off fixing a major bug because the culprit is on a two week vacation.

The goal isn't to have your team play "the blame game" or take bug counts too far (They're not all equal anyway.). Base it on who checked the code in last or have a supervisor make the decision and assign it to someone instead of going through every part of every line of code.

Better programmers probably end up fixing a lot of other people's code no matter how you assign it.