The longer version, she said, was more efficient.
She was one of two women who ran the IT shop at Ochsner Health Plan, in Metairie, Louisiana — fifteen people, and nothing moved without one of them reviewing it first. You finished an assignment and then waited, sometimes days, for one of them to get around to looking at it. I later fielded a call from a job agent trying to recruit me elsewhere, and it turned out he’d worked at that same shop himself. He didn’t need me to explain any of it to him.
My last assignment there was a forty-page program. I read it over and realized the same block of logic had simply been copied and pasted for every case it handled. I rewrote it in four pages, put the shared logic in one place, and brought it to one of the two managers. That’s when she told me the longer version was more efficient.
It is a whole lot easier to understand four pages than forty. I’ve built my own habit around that — I try to keep a routine to a single page, and when it won’t fit, I break it into smaller pieces rather than let it sprawl. Whatever she meant by efficient, it wasn’t that. It wasn’t the first time I’d watched a company mistake a working system for something else entirely, and it wouldn’t be the last.
* * *
Anderson Clayton Foods, Dallas, 1986. Their bill-of-lading system ran on a Datapoint machine that was already ten years old, and nobody left in the building understood how it worked. Nobody needed to. The clerks who used it were fast — each screen took exactly one field, and they typed without looking up, keystroke after keystroke, faster than most people could read the prompts. It was obsolete and it was loved.
The company decided to modernize anyway. They bought an HP3000 and hired a handful of contract programmers, me among them, to rebuild the applications from scratch. I got the bill-of-lading module. The specifications were bad enough that the analyst who wrote them was eventually fired — but not before I’d built the thing to spec. My code did exactly what the paperwork told it to do. When that turned out to be the wrong thing, I was the one who caught the blame.
* * *
A few years later, at ABRI, in Armidale, New South Wales, I picked up a system built the way people build things when they never expect anyone else to read the code. Every time the company signed a new client, someone had copied the existing block of logic and hand-edited it for the newcomer. Nobody had ever gone back and rebuilt it to handle a new client without copying the whole thing over again. After ten years, the program was an unbroken forest of nearly identical sections, and the only person who could walk through it without getting lost was the man who’d built it — and he had already left for Sydney. My boss knew exactly where everything was. He’d helped write it. Everyone else was on their own.
* * *
The last of these came from a bank in Dallas — I don’t remember the name — and I only heard about most of it secondhand, in an interview. A team had written the core system years earlier, in assembly or something close to it, and had kept it running themselves ever since — they could make any change asked of them, because they were the ones who’d built it. Eventually, they started to retire. The bank asked the remaining team to rewrite the whole system before they left. They refused. The bank dismissed all of them.
A new manager was brought in, and he was the one who was interviewing me. He estimated it would take two development cycles — five years — to get a working replacement built from nothing. I thanked him for his time and turned the job down.
* * *
Every one of those systems worked. That’s the part that’s easy to miss. None of these were stories about bad software — Datapoint ran fine, the ABRI system ran fine, the bank’s assembly code ran fine for decades. What none of those companies had was a second copy of the understanding that made the software make sense. It lived in one place: the head of whoever had built it, or maintained it, or fought with the specs long enough to know where all the wrong turns were. When that person left, the company didn’t lose a program. It lost the only one who still understood it.
I’ve spent a career trying to build the opposite kind of thing — small, broken into pieces, easy enough for someone else to pick up without me standing over their shoulder. It never seemed to be what got rewarded. But I never wanted to be the last programmer who understood something I’d built.
—
iStock image
