Strength Through Joy, in Cubicles
He was born with a gift of laughter and a sense that the world was mad.Roundabout communication, or secretiveRafael Sabatini
As a self-employed computer programmer, I once took contract work on a project where programmers in each section were forbidden to talk business with programmers in other sections. This was at Avco Finance in their shiny all-window sixteen-story building in Newport Beach, on a hilltop in view of the ocean in Southern California. There probably were a couple of dozen programmers who were employees of Avco, and as many who came in via a New York-based contract-programming outfit which was managing the big project.
Indirect communication was a management policy. For instance, suppose I'm writing a software module (semi-independent computer program) which interfaces my group's modules to your group's, and you're writing the corresponding module on the other side. These two programs' only business is to communicate with each other, passing bundles of data records involving an installment-loan or loan-refinance.
However, the corresponding people are forbidden to communicate with each other directly if we are assigned to different sections of the project. By official policy, we're not supposed to talk to each other about what we're doing. So if I have a question for you, I ask my boss, who asks your boss, who asks you; and the answer comes back the same roundabout way.
Presumably management wanted to keep all the strings in their own hands, by discouraging and even forbidding communication among workers on this complex project. And it was a fair-sized effort: I started about a half-year into it, when overall design was completed and programming just beginning. Already problems were being blamed on a chief designer who'd already left. The programming language was Cobol; the online software was IBM's CICS (Customer Information Control System), in which we were given token instruction but largely taught ourselves. I wrote what became the first big CICS program at Avco: the systems programmers used it to test their general utility programs.
My first programming assignment turned out to be a big one, eventually including over fifty subroutines. It was overly complex and took months to write, and more time to test. Naturally it had to exchange data records with other programs; naturally I had to know what data those other programmers would be sending my program, and how it would be arranged; and what I needed to send back to those programs, or to other programs.
So what did we do about communicating? Because we had to do something. Well, on my floor at Avco Finance then, the cubicles were laid out in clusters of four desks, each with a tall cubicle partition on three sides. Fortunately one of the programmers beyond a partition of my cluster was an old Avco hand, and helpful, so I would whisper Avco business questions to her through the partition cracks, and she would whisper the answers back.
This really occurred: I was there, I did it repeatedly, because it was the only way I could get my job done.
Avco Finance was the only place I've ever worked where business conversations in the hallways would turn into baseball conversations when bosses came by.
One may wonder whether such managers, like orcs, were created under the Shadow by the Dark Lord in imitation of workers. Their job definition is to foil workers and sabotage the company, passively if possible, actively when necessary.
This big project at Avco was mostly designed, or so they thought, before programming was begun. The fashionable design methodology of the day was called Top Down, which meant that you started with the big purposes and worked down methodically until you got to the nitty-gritty actual processing of data. Sounds good. Management was so obsessed with anticipatory design specifications and documenting everything that one of the programmers posted a little sign stating that Avco had a specs fetish. This was removed quickly by the authorities.
The actual approach to programming, however, turned out to be Bottom Up. That is, the small or even tiny specialty subroutines were written first. These might be used within, or called by, several or dozens of bigger programs. This programming methodology turned out to not fit well with the design philosophy. I found a neat old cartoon showing a bricklayer building an arched bridge, brick by brick: he'd just reached the top of the arch where he'd be obliged to start laying bricks downward toward the other side. I labelled this Top-Down Design, and posted it on a hallway cubicle wall, where it was appreciated by some. After a few days it was removed.
My first CICS program did a great deal of work, and with fifty-plus subroutines, it took months to write. It had been designed before I started at Avco, and not especially well, as I found out. As we began completing our first programs, we were told about Test Plans. The test plan for each program involved its programmer writing out some sample sets or test-cases of input values (say loan principal, interest rate, payment period. etc.), figuring out the corresponding output values, running the program with the specified input, and printing off the results which should match its test plan.
Okay. But now management informs us that we are supposed to do this for each subroutine within or called by our program; all its numbers in and out for each test-case. Whoops. For my own first program, this behemoth, I made up the overall input side of its Test Plan, 15 test cases that took 100 pages to write out. I refused to do the output side.
My bosses said, What? Why wouldn't you want to do the output side?
I told them that with fifty-plus subroutines, and having to work my way through the input and output side of each of those subroutines, doing a complete output side of a Test Plan with 15 test cases, would take a lot of manual calculation. I refused to do fifty thousand calculations by hand. I would quit first.
After some consideration, management shrugged and accepted this.
The programmer assigned to review my test results looked at them, and said, I don't know what I'm supposed to do with this. Looks okay to me.
Actually, the program turned out to run fairly well, for such a big, awkwardly designed thing.
The turnover on this big project was extraordinarily high. Sometimes a person would give notice of quitting, and before we had a going-away luncheon, another one of his or her friends also would give notice. During my first year-and-a-half contract at Avco, the turnover rate was over a hundred per cent. I was one of the long-survivors, or long-endurers.
Among the office graffiti going the rounds, one that was posted after a while at Avco seemed especially appropriate, describing Project Stages; it went something like this:
One of the girls had a looseleaf notebook with over a hundred pages of such graffiti that she'd gathered during several contract jobs. I wish I had a copy of that notebook now.
Management, understandably getting a little testy about subversive wall-postings, forbade non-business postings. I then put up a couple of neat old illustrations on my interior cubicle wall: one showing a 1930s gas-station pump with amazingly low 1930s prices, and the other reproducing a Pre-Raphaelite painting with a theme from Classical Greek mythology. Management looked at these but said nothing.
Sometime along then, one of the Avco employees on an upper floor, a woman not known to me, took a chair and bashed out one of the big unbreakable windows, and jumped a dozen stories to her death. I was told she left behind two small children. One of my programmer friends, a fellow who had known the woman and actually saw her falling past his own window, started getting up a collection for her kids. Avco management told him that this would be in bad taste.
Whereupon another friend, the woman programmer who was the old Avco hand, told me that she remembered that years back when Avco was headquartered near downtown Los Angeles, an utter stranger had been walking along the sidewalk, saw Avco and apparently figured it was that sort of place, entered the building, went to an upper floor and jumped to his death.
Some sort of corporate emanations, perhaps.
The nearby environment was very pleasant. One couldn't afford to live very close to our workplace, the neighborhood was too expensive. John Wayne's house wasn't far away. But the Pacific shoreline was close enough to drive to for lunch. I'd often pick up a sandwich and eat at the top of the cliffs at Corona Del Mar, reading in the fresh sea breeze and watching the breakers down below. Sometimes I'd go there after work, eat dinner there and unwind.
One of the fellows happened on an advertisement for the Indonesian national oil company, looking for business programmers to work in Jakarta. It seemed a great deal: fifty percent bump in pay, and they'd give you a house, a car, and three servants while you were there. The immediate visual attraction, though, was travel brochures: the company would give you an airline ticket with a couple of thousand miles of slack, so in traveling to Jakarta you might, for instance, stop off in Fiji, Auckland, and Sydney on your way to Singapore and thence Jakarta. Other guys sent away for these brochures, and management had to forbid them being spread out at work. Eventually six guys wound up going to Indonesia from Avco; although I heard later that none made it all the way through their contract there.
Toward the very end of my first contract, I was switched from writing online programs to testing batch programs which ran overnight. These programs were already written, their programmers had already bailed out. I was given a little subsystem to test, a set of seven programs which I'd never seen before, and told that these all worked individually: I merely had to test them as a sequence to ensure they all worked together, snap-snap-snap.
So I set up the seven to run, and the first one blew up: crashed. I asked my boss how I was supposed to test the set of programs together when the first one doesn't work?
He said that I was just supposed to make them work, somehow.
I said that since I had no idea what these programs were supposed to do, and their original programmers had departed so I couldn't ask them, could I see the documentation? The original design specifications according to which the programs were written? (Remember the Specs Fetish?)
My boss said there wasn't any documentation.
I didn't believe this, so kept pressing. Eventually my boss admitted that the management teams of the contract-programming company, and of Avco, had agreed not to maintain the design specifications.
So there was no explanation at hand for what these seven programs were supposed to do do, let alone how. I was appalled.
My boss, however, was helpful, in his way. A little later, he asked me when I would be done with testing the subsystem.
I pointed out that I could make no estimate, since I had little idea what the programs were supposed to do, and the very first one of the seven would not complete its processing. so I hadn't yet been able to try the other six.
In a placating manner, he proposed that I pick a date when I would be done testing.
At this point I invented my no door analogy. I pointed to the wall, and said: You're asking me when I can go through that door. But there is no door in the wall.
He didn't understand.
Wishing I was out hiking in the desert, I wrote out a couple of lines of a popular song lyric and taped them to the wall in front of my desk:
In the desert you can remember your name
Shortly after this, Avco and the contract-programming outfit parted company, with mutual but publicly muted recriminations. The contract-programming management gave me several weeks' good-will pay, perhaps so I wouldn't cause trouble, so I at least departed pleased.
After working at Avco a little while, being a history buff, I realized that their four-desk cubicle partition-groups were laid out (if visualized from above) in the form of Nazi swastikas. Naturally I had to share this useful insight with the crew, and many agreed it was symbolically appropriate. — Quite independently, the neighboring ritzy shopping center, Fashion Island, sometimes was referred to by envious would-be shoppers as Fascist Island. Some people have no respect.
When I returned to Avco Finance for a shorter contract several years later, helping extend the system of that earlier big project, the cubicle partitions had been rearranged to form hollow squares, four desks within each.
I was surprised and gratified when one of the fellows who'd been there while I was on my first contract showed me their departmental instruction notebook developed in the interim, a manual of Avco programming best-practices: extracts from my very first program for Avco and my first CICS program, that big one with fifty-plus subroutines, were provided as exemplars.
Working at Avco for these two periods gave me one component for understanding a fundamental dichotomy between the treatment of computer programmers by two of the major classes of employers of such folks. To a manufacturing company, perhaps in aerospace, respected engineers made the products by means of which the company existed; since programmers here essentially were another kind of engineer, they were treated well by management. On the other hand, to a financial-services company, unrespected clerks did the work by means of which the company existed; and so they thought programmers apparently were a weird individualist kind of expert clerks who somehow demanded and got way too much money, and were not treated well.
While I was at Avco Finance on this second contract lasting about six months, the only passing contact I saw between the vice-president of data processing, a manager five organizational levels up from us working analysts and programmers, literally was in passing: this director, ambling usefully down a main cubicle corridor, noted than one of the cubicle partions was a couple of inches out of true. He paused for a moment to line it up by sight with the partitions of adjacent four-desk squares, and proceeded on his important business.
My cubicle-mate programmer, without a moment's hesitation, reached over from his desk and jerked the partition back out of alignment.
© 2012 Robert Wilfred Franson