| 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! |