In software programming, as with any work with significant cognitive overhead, it's possible to hedge your thinking so far in one direction as to be blind to obvious solutions. The question am I being crazy here?
often comes up, or worse: it doesn't. It is indispensable in this situation to call upon another, fresh mind to point out what you're missing. In software, code review and pair programming attempt to solve this problem, but not without their shortcomings. So what if, instead:
During the implementation phase of a software project, for every three to six programmers tasked, one remains in fallow.
What this essentially means is that the fallow programmer would not have any specific coding task, but instead would circulate about the rest of the team, sitting with the other programmers while they work to act as a target off which to bounce ideas, give suggestions and get a feel for the other work her peers are up to — in what is effectively an official sanction of the kind of ad-hoc, everyday behaviour that occurs on programming teams. Of course, the obvious question here is:
Why would a software project manager deliberately commit such an odious transgression as the ostensible waste of programmer time?
First, it is well-known that productivity drops and mistakes increase when workers do the same thing for too long. This is why when you're at the airport, you see TSA employees continually shifting positions. By giving programmers' brains a periodic rest, clearer thinking and direction can manifest.
Some companies, notably Google, allocate a percentage of their technical staff's time to side projects partially for this effect, but anecdotal evidence suggests it gets eroded when schedule pinches arise. The fallow pattern would stay in effect regardless of the schedule's situation, and occur on a rotation, rather than being pinned to any particular day of the week or scraped together ad-hoc. It should also be noted that since the fallow programmer is acting as support personnel, at least some of her time would be billable.
Second, and the reason not to waver in the face of a tight schedule, is that the programmer in fallow would essentially be working on the team's main project, just in a different capacity. In holding short consultation sessions with other programmers at their desks, our friend in fallow can observe their progress, learn or teach techniques, as well as preemptively spot bugs, conceptual flaws and style misfits.
When a team completes a few rotations, all programmers ought to have accrued a reasonably intimate understanding of the tasks, skill levels and habits of their team members, as well as a greater insight into the project as a whole. This behaviour can also be parlayed into other valuable curatorial activities, like spotting code redundancies and larger design flaws, or even recording time sheets for the other programmers.
Third, when not visiting with her peers, a programmer in fallow has an opportunity to prune her work environment, participate in company e-mail lists, craft custom scripts and tools, edit documentation, update the knowledge base, bone up on the latest technology trends, or any other useful maintenance-oriented task that so easily falls by the wayside in a typical programming environment.
This article mentions code reviews and pair programming. What's different about this method?