| « | Fran's Sunday Ruminations: In The Wilderness |
»
|
|
Monday, September 26, 2005
From The Bit Bucket: Babysitting
You never get the last thousand bugs out. -- Software engineers' motto, first sighted at IBM
An enduring myth of the engineering trade is that a product is "finished" on the day it's deemed to have passed its Acceptance Test Procedure and is released to its customer community. Since it's finished -- that is, since the foreseen work on it has been completed -- obviously, it should consume no more of anyone's time or effort. Those who brought it to life may be regarded as free for other duties.
It takes a new software engineer about one project to learn that this is the world's most arrant nonsense. However, dispelling the notion from the heads of middle managers has proved near to impossible. Even some of your Curmudgeon's front-line colleagues have shown a propensity to believe it.
Well, a thousand pardons for being so remorselessly realistic, folks, but it just ain't so. It's not true most of the time. It's not true some of the time. It's not even true in the occasional rare case. It's never true. No software product ever developed, or ever to be developed, is finished on the day it's first released to its customers.
This is in accordance with a phenomenon so universally observed that it might be a law of nature: The customer can break anything. Given sufficient time and incentive, he most certainly will.
An Acceptance Test Procedure is an engineer's sincere attempt to anticipate what the customer might do, and to assure himself that he's prepared for all of it. But no engineer has the customer's gestalt from which to work. No engineer can really put himself in the complete outsider's position from which his customer will approach his product. So, hard as he might try, his attempt to guarantee that his program is bullet-proof will fall short of the mark.
This gives rise to the requirement for babysitting.
A product freshly released to its customer community is like a newborn baby. It will frequently need to be cleaned up. It will frequently need to have its diapers changed. It will wake at odd hours and screech like a jaybird until it receives some cuddling. And now and then, it will succeed in getting hold of the tablecloth and pulling one's entire seven-course dinner down to oblivion.
Someone has to watch the little wretch. That will take some of his attention, and sporadically, all of it, until the little nuisance has been toilet-trained, taught not to play with the knobs on the stove or with Daddy's electric drill, and packed off to kindergarten.
With some programs, this couldn't be more obvious. For example, Microsoft maintains full-time support staffs for Word, Excel, Access, Power Point, and Windows itself -- a separate staff for each of them, not one for all. These programs are incredibly complex. The power and flexibility they offer to the customer, and the concomitant multiplicity of their internal states, practically guarantees that no matter how much time should pass, there will always remain a way to break them. Granted, those ways will become more obscure and more bizarre over time, but until the day Word is obsoleted forever, it will remain possible for a customer to break it.
The best conceivable support engineer is he who designed and implemented the product in the first place. He might resist being assigned the responsibility. Most engineers would; support work has low prestige, and precludes new development to some extent. But the necessity will remain, and he's the man for the job. Therefore, for an appreciable period after the product's release, he'll be at least partly unavailable for other duties.
So what the hell do you think you're doing, Mr. Middle Manager, demanding that that engineer be reassigned full-time onto some entirely different effort, right from the instant of his current program's release?
You're demanding that he put in overtime, that's what you're doing. At most shops, engineering overtime is unpaid. So you're demanding that he donate to the company the time he'd otherwise have free for his family, his pastimes, and his other obligations, in exchange for...what?
For an enduring state of exhaustion. For one sleepless night after another, wondering which of his obligations he'll have to shortchange next. For the sense, damnably hard to dispel, that everyone around him wants a piece of him and no one cares whether he bleeds to death.
Among a front-line manager's highest responsibilities is to protect his subordinates from unreasonable demands. There can be no more unreasonable demand than that a worker give his job first claim on every hour of his life, at his employer's sole discretion and for no consideration whatsoever.
Every product needs a babysitting interval, just as every engineer who's slogged through an extended development effort needs spin-down time. The two should be mated to one another; the engineer should not be asked to pay any attention to anything but his new product for the first few weeks after its release. His transition over to new responsibilities should be gradual and gentle, for his attachment to his existing responsibilities will never really end. At least, not until his product is completely superseded by something else.
And on that fateful day...
How are your skills at grief counseling?
Comments
In this regard, engineers working on actual product may be seen in the same light as “creatives”.
It is one of Murphy’s myriad laws and corollaries that management don’t understand creatives and will always mistreat them until such time as they (the creatives) are induced by maltreatment to jump ship.
At which point management will express bafflement as to why.
M
Posted by Mark Alger on 09/27/2005 at 12:05 AMNot that I think Mr. Alger is wrong...but it really has nothing to do with that. This is simply how middle managers treat people, whenever labor market conditions are such that they can manage to get away with it.
A year of 20-hour days (in a job where I wasn’t even doing product development or anything else analogous to “creative” work) proved that to me quite nicely. Lucky I wasn’t married...I’d surely be divorced now if I had been.
To anyone who works for a company large enough to have developed tumors of “middle managers” and yet still doesn’t know what it’s like to sleep under your desk and shower only during once-a-week visits home...well, you’re lucky, and I hope you stay that way.
Posted by Matt on 09/27/2005 at 02:42 AMEngineers are mostly from a highly competent prey species that are unfortunately incapable of defending themselves.
Think sheep with really big brains.
Middle managers are an incompetent predator species, but they’ve been given belt fed machine guns.
Think Wile E. Coyote/Ralph Wolf.
As a competent engineering manager you are a different species entirely.
You are Sam the sheepdog.
Posted by Chris Byrne on 09/28/2005 at 12:19 PM
Comment Form
Commenting is not available in this weblog entry.
