4 ms·
I think the core issue the author seems to be getting at is bigger than just the Bazaar (Open Source). Even when it comes to closed source commercial software
by georgemcbay 12y ago
I think the core issue the author seems to be getting at is bigger than just the Bazaar (Open Source).
Even when it comes to closed source commercial software development I really miss the days of code ownership. When I first started working as a programmer back in the 90's it was common for different members of the team to "own" sections of code in a larger system (obviously I don't mean "own" in the copyright sense, just in the sense of having one clear person who knows that bit of code inside and out (and probably wrote most of it). Of course we'd (preferably) still be beholden to code review and such and couldn't change things willy-nilly so as not to break the code of consumers of our code, but it was clear to all who to talk to if you needed some new functionality in that module.
The last few places I've worked for have been the exact opposite of this where everything is some form of "agile" and nobody "owns" anything and stories are assigned primarily based on scheduling availability as opposed to knowledge of a certain system. There is admittedly some management benefit to this -- easier to treat developers as cogs that can be moved around easily, etc, but my anecdotal belief is that this sort of setup results in far worse overall code quality for a number of reasons: lots of developer cache-misses when the developer is just bouncing around in a very large code base making changes to various systems day to day, lots of breadth of understanding of the system among all the developers, but very little depth of understanding of any individual component (which makes gnarly bugs really hard to find when they inevitably occur) and what should be strongly defined APIs between systems getting really leaky (if nobody 'owns' any bit of the code it is easier to hack such leaks across the code than define them well, and when your non-technical managers who interpret "agile" in their own worldview force developers to try to maintain or increase some specific "velocity" shit like this happens often).
Granted, there are some cases in which such defined ownership falls apart (the person who owns some system is a prima donna asshole and then everyone has to work around them in painful ways), but there were/are solutions to such cases, like don't hire assholes and if you do fire them.
- fsloth 12y agoI switched teams from one with a communal codebase to one with code ownership (within the same org). The code ownership style has far better developer productivity. But I think the issue is just not about team organization, but also of software architecture. I think with code ownership the modules need to be small enough so that if the owner exits unexpectedly from the organization someone else can pick up from where the previous owner left. With communal software that gets built and tested after each build its very easy to let the architecture slide into a structureless mud ball that works but nobody is quite sure how, especially with changes being diffused throughout the system with concurrent edits by different developers.l
- ajuc 12y agoWe did code ownership, then very important developer left, and we did pair programming for a few weeks and then no code ownership (and people were assigned tasks from different parts of code) for a few months. Then we went back to code owenrship. I think it was reasonable solution - better productivity, but people know more or less where to search for something, even if John isn't available when the bug hits. I particulary liked pair programming and would like it to happen every few months for a few days.