Saturday, November 10, 2007

Developing In Silos Burns Cash And Costs You People

This is for forwarding to managers who are shooting themselves in the foot.

Recently I interviewed at a 100-year-old company. Four developers told me what they did, and it was evident that two of them worked on one area of their project, and the other two worked on a separate area. I asked them if they were worried about collective code ownership or re-inventing each other's wheels due to the isolation of their thinking, and they replied that they'd had a meeting about that very issue that morning. It was very much on their minds.

I mentioned my visit to this company to a friend of mine, a technical manager, and his first thought was, roughly, "You have to be careful with a nontechnical company with technical sections in it, because the company already has a system which makes certain people primary in terms of importance, and that system will dominate the technical sections of the company, even though it may be detrimental or dysfunctional for technical projects." To some extent, that's exactly what was happening: the developers told me that the reason they're operating in silos is because nontechnical people need single points of contact for particular projects, and they're mapping those single points of contact to "Bob works on Project X, Joe works on Project Y." As intuitively obvious as that is, it's also guaranteed to cost you money.

Programming is intricate and systematic. If two programmers at the same company do the same thing twice, it's virtually guaranteed that they'll do it in different ways. If these two programmers see each other's code, they'll recognize the repetition, and look to eliminate the repetition. The more systematic and less task-specific your code is, the easier it is to work with. Also, if two programmers see two ways to handle the same task, because they'll want to systematize the task, one way of handling the task will lose and the other will win. Usually the best way to determine which of two ways of handling a task wins is to show both ways to as many programmers as possible. That's essentially why open source works so much better than closed systems.

This is also why programmers have evolved the practices of pair programming and code review. Pair programming and code review are very effective techniques which prevent the accumulation of technical debt. Programmers hate technical debt - if anything, more than managers do. Some kinds of programming work are fun and some kinds of programming work are horrible. Developing new stuff is fun. Debugging a badly-built system is horrible. Managers should avoid building bad systems because it's essentially technical debt; anything you've built badly, you'll have to rebuild correctly at some point in the future. The time you save now you'll just have to spend further down the line, and just like financial debt, technical debt snowballs. But programmers avoid building bad systems because when that time comes, and management inevitably realizes it has to pay off its technical debt, programmers are going to have debug a badly-built system, and that's horrible. Programmers like to avoid building stuff which will have to be debugged because they'll be the ones doing the debugging.

(This is also why building stuff with contractors, and then hiring permanent staff to keep it running, is a much riskier strategy than many people suspect. The normal incentive to avoid doing things which you'll have to fix later is that you'll be the one doing the fixing. When you aren't the one doing the fixing, and somebody else is, human nature means something slips through the cracks.)

I've seen technical debt created this way in teams as small as only three developers, but once you scale past six or seven, that's when the technical debt really starts piling up. That's when you end up with a crucial component everything else depends on, written by just one person, and you realize that if this person gets hired away or hit by a bus, your whole system falls apart overnight. That's the difference between agile and fragile. Although I don't think this company was in quite that much danger - it's not even necessarily a hard and fast rule - the point for companies generally is that this is the kind of thing which you have to address, and which it is much better to address quickly.

The idea of "Bob works on X" is so intuitive and natural that the only way to prevent it from ossifying in that dangerous way is to nip it in the bud. I believe the solution is to implement pair programming as early as possible - ideally before the first line of code is ever written. The association of person to task comes from normal human behavior, not an org chart, and a natural, emergent dysfunction cannot be fixed by an org chart, even though, at some point in time, someone will try. It's like preventing heart disease. Nobody's found a dependable cure for heart disease, but preventing it is pretty simple: exercise and avoid cheeseburgers. The earlier you start that, the better it works. This fundamental approach to preventing toxic buildup works in organizations too. Make sure there's no hook for this natural human behavior to hang on, and some other, healthier natural human behavior will emerge.