Whenever I read articles like this, it makes me wonder why half of it even needs to be stated; then I go and look at the code base for some of the companies that I do development for. At that point I realize that, planning, documentation, and "fixing broken windows", are all activities that you need to build into the core values of your company from the start. They need to be so ingrained in the culture, that people participate in them on an intuitive level, instead of it being a after-thought. The time spent working around "known bugs" far (exponentially) exceeds the time it would have taken to fix them before they were part of the current stable release.
I like the "bus factor" discussion. It's #3 in the article. In the projects I've been a lead on, the bus factor is in a sense 1: each hacker is responsible for their own module, and while others might read their code, they don't contribute (except report bugs).
However, the modules are set up so that there is a clean separation between them, with all interaction being through well defined API's. In fact, each hacker typically uses their own server unless/until efficiency constraints force us to do otherwise. So far it's worked well. If one person goes away, the project can continue until they come back or one of the others can learn/duplicate their module.
This allows us to dramatically increase prototyping speed, but may not be sustainable as project size increases.
I'm fairly inexperienced, so I'd like to know what you guys think about this practice, since it's something I think about a lot.
#3 - Seems to indicate that everyone in your team must be replaceable. This is good from a management and operational perspective.
...but you can't stop people who are just damn good. In fact, often this hampers them - i.e. You're too good at X, so you have to train a whole bunch of people who are bad at it otherwise it's a risk. This is often applied irrespective of the skill/talent of the person involved and the rest of the team respectively.
Sometimes people just are irreplaceable. What you don't want are people who are irreplaceable because of systemic issues.
Bridging the gap is always a pain. As a freelancer, I find that often I need to steer clear of "better" (though perhaps technically complex) solutions at times because I know it may create a panic when I leave. It's frustrating to "play to the crowd" but I have also found it can be just as bad to leave companies with elements their in-house employees can't figure out.
Irreplaceable is good. It means that person is a superstar. Keep them happy (and safe!).
One danger I have seen manifest itself when splitting code up into well defined areas is that participation in the code base as a whole drops significantly. You might get a few drive-by bugs between areas, but not the kind of serious review you give your own code.
Also, when one person is "responsible" for an area, one area is almost always the limiting factor (for development speed, quality, etc.).
Finally, having clear areas of responsibility like this mean that the manager of the developers can reinforce bad behavior (i.e. this bug is not MY fault, see, it is in HIS area). Then, everyone sits around and complains instead of someone just pitching in and fixing the bug.
I couldn't agree more. I think the distinction is that inherently irreplaceable people are irreplaceable no matter where they are put. Some people are irreplaceable just because they're the only one that knows anything about X.
I'm also fairly inexperienced, but it seems to me that as long as there is a clean separation between modules (which there should be anyway), that it would work rather well.
Architecture astronauts should take careful note of points 7 and 9. I've read some obsessive-compulsive discusions regarding RESTful design around here lately. You don't see much focus on the customer.
