by Conrad Weisert
June 15, 2010
© 2010 Information Disciplines, Inc.
This article may be circulated freely as long as the copyright notice is included.
|"Sorry, Herr Beethoven, you must finish this string quartet before you start on another symphony."|
I've attended a distressing number of incompetent presentations this year, and I'm eagerly awaiting some sign of improvement. Last week one of those agile enthusiasts warned us against "task switching" while we're programming. Once a programmer starts working on one task, the speaker advised, he or she should persist until that task is completely finished. Why? Because:
When we're mowing a lawn or painting a room, we may get sick of the task but we know that we're better off sticking with it until it's done. Programming, on the other hand, is a creative process. We often get stuck in a rut and need to clear our minds. When we return later we may gain a fresh insight or we may spot something from the earlier session that we now regret. A break usually improves the quality of the code. Last week's speaker obviously had no notion of program quality.
There is one situation, of course, in which the programmer will feel lost returning to something from last week or even from yesterday: if the partially-done program is an undocumented mess! But in a well-managed organization with competent programmers that should never happen. If the programmer begins each assignment by stating clearly what the program component does and then organizes the code in a logical manner, it will take little or no extra time to pick up the context later.
Trusting the Programmer
Oddly, the speaker who insisted that programmers mustn't be allowed to switch tasks had just advised in the same presentation that programmers should be free to deviate from or ignore their organization's programming standards! "Because they're closer to the actual work," he explained.
That was an example of a phenomenon that we often see when organizations try to establish a disciplined approach. Some consultant or in-house guru may insist that certain principles that he favors have to be mandatory standards while other principles arising from the normal approval process should just be advisory conventions.
A key component of extreme programming and other so-called "agile" methodologies is pair programming, the belief that two programmers, sitting together at a keyboard and screen, will tend to produce a higher-quality or more timely program than a single programmer working in private.
This is a special case of the task-switching prohibition discussed above. If I don't feel up to pounding away at a puzzling task, having a partner depending on me to persist until it's done just increases the pressure. With pair programming it's extra hard to switch to something else, and the pairs typically push through to the end. The programs they produce often show it.
The respected methodologist Joel Spolsky noted
Reconsideration: Two separate issues
I made a mistake last month in combining the pair programming issue and the task switching issue in the same article. A couple of readers whose experience I trust have assured me that working with a partner does not necessarily increase the pressure to stick to a single programming task, and that even when it does, the partner may bring a fresh insight that expedites completing the task.
Read James Grenning's thoughtful response for another
"I can't tell you how many times I've been in a meeting with even one or two other programmers, trying to figure out how something should work, and we're just not getting anywhere. So I go off in my office and take out a piece of paper and figure it out. The very act of interacting with a second person was keeping me from concentrating enough to design the dang feature."
Consider this C++ program statement:1
assert(!((!Parm.activation.isPropertyContained) || (Parm.activation.isPropertyContained && ! Parm.activation.isTransactionIDSame) || (Parm.activation.isPropertyContained && !Help.CheckImplementationsFit())));
That qualifies as utterly atrocious code with no conceivable redeeming value. It's virtually impossible to understand, with its double negations and repeated terms. To try to modify it would be dangerous. It actually yielded correct test results, but would you want to be a maintenance programmer trying to diagnose an error?
I have no certain knowledge of how it came to be; the program was written in an exotic land halfway around the world. But in a telephone conference call, the pronoun "we" gave a strong indication that more than one programmer was the author.
Even without that evidence, however, I could easily have guessed that pair-programming was at work here. What possible thought process could have led a single programmer to produce such a convoluted mess? But we can imagine two programmers running unit tests. One of the tests fails. One programmer assures the other that he knows how to correct the bug. He inserts another term with the necessary parentheses, and the test now passes. They move on to the next part of the program.
The issue is managing one's time. A single programmer concentrating on solving a problem may elect to reflect upon a partial solution, to tidy up messy code, or to switch to another problem and return to this one later with a clear mind. Two programmers working together, however, are unlikely to do any of those things. If I interrupt our shared rhythm of coding and running unit tests, I'm going to waste my impatient partner's time.
In the case of the atrocious example above, we can be fairly certain that a single programmer, not constrained to keep plugging away at a messy task, would soon have transformed the code into this:
assert(Parm.activation.isPropertyContained && Parm.activation.isTransactionIDSame && Help.CheckImplementationsFit() );
Whether a programmer sticks to a single task or switches among multiple tasks is really irrelevant if the programmer's commitments have been agreed to and recorded in the master project plan. Suppose a programmer's current assignments are:
The project manager doesn't need to micro-manage how the programmer spends his or her time. The experienced programmer knows the urgency of each task and its relative difficulty. He or she will make sensible choices in order to meet the commitments.
A manager (or lecturer) who doesn't understand lacks understanding of both programming and project management.
Return to table of contents
Return to management articles
Last modified (minor correction) November 27, 2010