Cross Pollination
I get bored easily. As such, I always want to move around to different projects to keep myself challenged, break up the routine, and get fresh perspectives. Luckily my current line of work, consulting, gives plenty of opportunity for this sort of intellectual wanderlust.
One surprising side-effect of my thirst for new projects is that it seems to result in higher quality output, especially in terms of code maintainability. I’m going to call this effect cross pollination. By moving developers around within the team to work on different components, no area of the code becomes the exclusive domain of just one person. This in turn results in healthier code, because different people are examining and trying to understand any given module. They ask questions like “Why does this bit of code work this way?” - a question very rarely asked of code one is familiar with.
If something is hard to understand or change right now, it’s probably going to be fragile over the long run. (It’s like the old technique for programmer job security: “If it was hard to write, it should be hard to understand and even harder to modify.”)
This article advocates a common approach to this problem: get programmers to train other programmers on the quirks of the codebase. I see this is little more than a bandaid. The real solution here is not to let software turn into quirky, only-one-or-two-people-know-how-it-works code. Cross-pollination of developers ensures that people are always writing code that is understandable to any other developer. The important thing is not having a certain number of developers that know the code, it’s making sure that you’re getting new eyes on the code from time to time.
A truly well-written piece of software can be easily understood and modified by any component developer familiar with the underlying tools. They need not “know” the code. Reading it - and especially reviewing the unit tests - will give them all the information needed to fix bugs or add features.
September 19th, 2006 at 9:04 pm
Ahem…seems all to closely related to a recent issue with some code very near and dear to a site crafted solely by_just_one_programmer.
How would one propose to turn an “only-one-or-two-people-know-how-it-works coded” site into a open book for all that must tinker with it?
September 19th, 2006 at 9:10 pm
Heh…. yes sir, you’re right on target. For an existing codebase which has crown quirky and crufty due to inbreeding, there are two potential options. One is try to begin to carve into it with fresh tools and techniques designed to beat it into shape. The other is to give up and rewrite from scratch. Which is cheaper or more appropriate is a judgement call. For the site you are referrencing, I think it can be salvaged, but it would require application of some modern tools (tools that didn’t exist when it was firs tcreated), coupled with a lot of time and discipline. Other projects I’ve seen simply could not be saved this way, and had to start over from scratch - which is not as bad as it sounds, because the original project can serve as a design guideline, greatly reducing development time of the new site.
September 20th, 2006 at 9:10 pm
A good starting point for code in that state is normalization–achieving a state where each piece of code appears only once. Multi-file diff tools are valuable in this phase of refactoring. Eclipse plugins, some Zope tools, and aspect interceptions can be great refactoring shortcuts, too.
For a codebase at that stage, unit tests are a bit overrated/impractical–testing at the module- or use case-level is often more effective.
When making the scratch/refactor decision, please consider carefully this advice. Note the context, however: he’d been with that company for years & wrote a good chunk of the code.
I’ve noticed a trend among younger consultants to accept only blue-sky or new projects, the effects of IT fluctuations & a generation raised on ‘Internet time.’ It may have positive short-term effects for individuals (more lucrative; buzzword-compliance). But I feel it is harmful to the industry: your cross-pollination lessons are less likely to be preserved, buzzword-chasers get over-publicized & -capitalized, and consulting becomes less of an opportunity for intellectual wanderlust than janitorial wanderlust. To this end, I take maintenance contracts every other year & am considered a bit odd in this. It’s an opportunity to learn refactoring & others’ coding patterns (be they adaptive or maladaptive), and a big step towards becoming a well-rounded consultant. After all, someone’s going to maintain _your_ code.