December 14, 2000
I really like Dilbert. The comic strip, that is. The one where the office characters spend their lives in little cubes struggling against impossible odds: management. Like all comic strips, though, it’s an exaggeration.
I mean, really: management can’t be that bad can it? Can it?
The new broom
Not too long ago, an insurance company I worked for decided to install a state-of-the art Software Management and Security System. Well, that’s not exactly true. A senior VP from accounting decided the technical staff was not to be trusted with the handling of software and all that fancy stuff.
Someone even farther up the ladder, and even further divorced from reality, had appointed him generalissimo in charge of computers. And he was about to impose some order on his subjects.
Senior technical staff members were grudgingly allowed to examine the package, which had been thrown together by a salesman, a graphics designer, and a junior programmer fresh from high school. They laughed out loud, bounced the whole mess back to top management and forgot about it.
Until the following month, that is, when the junior programmer appeared and proceeded to install it.
Apart from a few major disasters resulting in delayed payroll, a lawsuit from a disgruntled policyholder and the resignation of the DP manager (and one of his best technical people), the installation was smooth. Only a month later, we had a state of the art system. That’s when the real trouble began.
The perfect software
You see, this was an airtight system, designed to ensure that no one could move any piece of software, however insignificant, up the line and into the production system until it was pristine, polished, and perfect. Each change had to be meticulously recorded on special online forms, each form had to be signed by an entire hierarchy of users, potential users, and middle management. Most of whom had no idea of, or connection with, any of the software being moved.
“Ok,” I hear you say, “we’ve all had to deal with that sort of situation.”
All we had to do was sweat it out, right? Wrong.
You see, the junior programmer, a candidate for management if ever there was one, had seeded the software with time bombs. Literally. Steps not taken and hurdles not cleared within a certain time caused the software to reset itself. You were back to square one. The whole process had to be restarted.
We spent minutes coding and testing small changes. Then we rushed round like dervishes for hours, trying to find the human resources supervisor, the data-entry clerk, the janitor, all the myriad personnel from the dark recesses of obscure departments who had to enter their online say-so for us to continue.
No matter that A. Jones was on vacation, or having a nervous breakdown, or dead. We needed that authorization, and we needed it within a few hours. Nothing, and I mean nothing, got past that system. Junior, in his infinite wisdom, had not allowed for emergency situations. Luckily, no major bugs were found in existing software, but the on-call programmer was called at 2 a.m. daily to patch the database, since he couldn’t get a fix cleared.
Eventually, he quit.
The other shoe drops
After three months our users began to get a bit snippy. Were we partying all day? Was anyone doing any actual work? We sent a delegation to see the Senior VP. We explained that we were spending all of our time trying to get past his security system.
Twenty experienced coders, spending eight to ten hours a day trying to jam program changes into a machine, which had been choked by his software. I have to say, the man acted like a real manager. Within a couple of days, we were introduced to the new trainee programmer, hired to do what twenty of us couldn’t. He was full-time administrator of the Security and Data Management system.
The kid came in bright-eyed and enthusiastic, and quit, a broken wreck, three weeks later.
Our users were getting really, really angry by now, and it was obvious that our glorious leader was spreading the word that his troops were incompetents and quitters, unwilling to accept change and progress. And indeed, deprived of all hope, feeling like soldiers sent on suicide missions by a crazed commander, we were dropping like flies.
By month six, what was left of the staff was staring, shell-shocked, at the wall for most of the day.
St. Mary, the contractor
It has been written that only in times of great trial and tribulation do great leaders arise. Well, it’s been written by me, anyway. Our Joan of Arc was born in the unlikely person of Mary the contractor.
Affectionately known as Typhoid Mary, she could out-swear anyone on the floor. She wore leather jackets and jeans salvaged from the rubbish dump, and she didn’t bathe too often. But she became our hero.
St. Mary the Contractor returned from a particularly bitter session with one of our users, cursing and rumbling, and set to work digging through our meager store of documentation, hacking the data management libraries, and interpreting the undocumented spaghetti code that comprised our package from hell.
She had always been good at her job, but fury and frustration turned her into a superhero. When I left, late that night, she was still in full swing.
The next morning when we drifted in, her desk was clean and unusually tidy, and we feared the worst.
She had left us all an email, written in the early hours of the morning. She was, she told us, taking a few days off. With unaccustomed humility, she asked one of us to please move all her changes into the production system, now that the security package was fixed. There was an attachment, beautifully documented, telling us how to do this. Everything was made simple. There was a secret way to get around all the diabolical security traps. Now she had documented it.
That week we shoveled all of our changes into the production system, bypassing all controls. Little glitches were fixed, major improvements were initiated, our users were happy, and everyone congratulated us on our productivity, except our Lord and Master, who said he was glad we had finally managed to understand his little software package.
Mary decided to move on to greener pastures, but we managed to get her to come to a farewell lunch, which she attended, looking a little nervous and surprised at being so popular. We decided not to tell our boss that his security package was working without any security, but the last I heard, everyone was happy, and it was still in use.
The real deal
A few weeks later, I was talking to my neighbor from the next cubicle. “It’s amazing,” he said, “how much smoother everything runs now. It even seems to run faster.”
He meant the security package, which we had taken to calling ‘Mary’s Package.’
“I’m surprised,” he went on, “that we never figured out how to move changes up in emergency mode. Stands to reason, there had to be an emergency mode. No piece of software could be that bad.”
“True,” I told him, but I knew better. After the farewell lunch, I took a look at Mary’s package. ‘Fixed’ was the operative word. Like you fix a dog.
It really was Mary’s package, faster now because she had scooped out all the code. Practically all that was left was the ‘Module successfully moved into production’ message at the end.