[yuhe00]

Maybe I've just been unfortunate/fortunate, but in 6 years as a software developer on all kinds of projects, I've never once worked on a project where even two people share the major contributions to a single repo. Either I run away with one part of the project or someone else does while I work on some other part. Usually split between frontend/backend/devops (webstuff) or app/libraries/tooling. We obviously plan and discuss how the different parts of the projects work together, and we do make contributions to the other repos, but these are usually minor.

I don't necessarily see it as a bad thing. It just feels the most natural, reduces friction and the need to communicate minute details. Ownership is also important. The downside of this is that some part of the project might fall apart if someone leaves, because no one else can take over.

[pojzon]

> The downside of this is that some part of the project might fall apart if someone leaves, because no one else can take over.

This is the reason, i think, corporate world HATES with passion such devs. Even tho they need them to meet deadlines.

It also gives a bit too much power in negotiating to the employee which is also seen as "bad" in corpo.

[luckylion]

> This is the reason, i think, corporate world HATES with passion such devs.

Which is the right attitude, imho. Even if that person loves the company and would never leave - what if a bus runs them over?

On a large scale, consistency is more important than excellence. You need to be able to plan, "if that guy stays, the project will be done in 4 weeks, but if he leaves, it will take four years" just won't work, because you cannot rely on it. It's much better to be able to say "it will be done in 12-14 weeks" with high confidence. Sure, your whole dev team might get run over and spoil your plans, but that's really a case of force majeur.

[rabidrat]

Okay, so let's be optimistic and say a team of 4 can do in 12 weeks what that one dev could do in 4 weeks. 48 dev-weeks vs 4 dev-weeks. Do you think it's reasonable for a project to cost 10x as much just for that precious consistency? Not to mention that longer projects with larger teams have higher variability in outcome, with most projects overshooting by 100% or more. Is this really the right attitude then?

[luckylion]

> Do you think it's reasonable for a project to cost 10x as much just for that precious consistency?

Somewhat, yes. You want to be able to plan. Inefficiency is often the price for being able to plan. Since it's often not only about this one project, a higher price is just fine - you may have to coordinate with marketing, legal, sales, manufacturing etc, then the total price will often be so large that the 10x of the software project doesn't really matter, but if it falls flat and gets everything delayed, the damage may be huge (think global launch date missed).

[katbyte]

No to mention if its well written and documented it's not impossible or even necessarily all that hard for another talented dev to ramp up and take over...

[Data_Junkie]

What they hate is losing power. They want power that they can only get by using the power inside others. Hate is just the energy to justify oppressing and using other minds for things theirs can't do. Also known as capitalism. What they hate is not owning and controlling their own little world.

[mikekchar]

I like non-ownership style development. Don't get me wrong, I also enjoy ownership :-) I will guess, though, that the feature size that you work on is fairly large. For example, if someone wants something done, you go away for a week or so and do it. This is the style of programming that I grew up with so I'm quite familiar with it.

I changed to a different style of programming where we break the "features" into much smaller parts called "stories" (yes, I'm one of those -- XP developer). I try to make stories about the size of a day... If you've been doing the week (or more) kind of stuff, it seems impossible to organise work at this level of granularity. In reality, it is usually possible to break things up into very small vertical slices. However, it is admittedly quite difficult.

The small slices really enables non-ownership on the team. There are a host of very nice benefits for non-ownership. It's actually a bit hard to explain, unfortunately.

First, non-ownership tends to force you into conflict early. This doesn't sounds great at first (and for some teams, it is definitely not going to work). However, it's usually better if people on the team sort out how they want to work early so that they can develop a good rapport instead of silently begrudging each other. Everybody has strengths and weaknesses and by being able to work closely together you can capitalise on that. I actually only resort to ownership if it becomes obvious that some people can't work together.

Swapping people in and out of code also results in them having to get up to speed in it. If the code is easy to understand, then people are happy and get up to speed quickly. If not... then ideally you want people to refactor the code. Umm... see the part about "conflict early" LOL. After you have a good rapport going, you'll have programmers refactoring each other's code and you'll have them be thankful for the result (honestly!). Yeah... I know.... You'd probably like what I've been smoking ;-) But it's true.

This constant vetting of code and refactoring leads to a much simpler code base. The final result is that you are able to maintain your production over long periods of time. On the best projects I've been on, we've actually improved our perceived productivity as we've added more functionality.

This seems odd, because it's the opposite of what you'd expect -- more functionality means more lines of code which means more complexity which means slower going. However, if you think of a modern OSes, languages and frameworks, we are building on huge piles of code. But the reality is that these underlying systems undergo massive churn because of the amount of use they get. In the end we get software we can build on that is stable and simple to use -- the more underlying code, the faster we can build new systems.

In my opinion, one of the most important aspects of getting to this seeming utopia is to avoid code ownership. It definitely doesn't always work and it's definitely not good for some people and some teams. But when it works, it's pretty damn amazing.

I hope that provides a bit of counter point to your experiences. I still like ownership, though... That's why I have my own private projects ;-) I'm pretty loathe to share them with anyone!