2013 — Write something else funny...

... for the Christmas issue, will you? Another simple enough request I received (this time, back in 1996) from the editor of the IBM Hursley Lab's in-house staff magazine. I rediscovered this text today while taking the revamped, and already patched, Copernic Version 4 desktop search tool out for another exploratory spin:

Something else funny?

I had so many positive comments (zero is positive, isn't it?) about my little Babbage item in last year's Christmas issue that the editor had no trouble at all persuading me to try again. Harder. "Just be more modern", he said. So I thought this year I'd share with you a few more of my Hursley-oriented literary acquisitions (I doubt you're interested in my history of Underground Comix, and I further doubt that "Developments" could afford to be busted...).

I've been torn delightedly between several texts. Top of the pile is "Why things bite back" (Edward Tenner, 1996) — a depressing tome on new technology and what the author calls the revenge effect. I seem to recall from my days as an SF reader a dictum along the lines of the perversity of the universe tending towards a maximum. Dr Tenner asks poignant questions such as "What makes e-mail less efficient than a telephone call?" and "Why does staying relaxed demand ceaseless effort?"

On "the inflation of code" Tenner comments that "programmers and developers are understandably working for the future, preparing for the next generation of machines. Most users are living in the past because either their budgets or their bosses won't let them upgrade hardware to the current standard... Users who do not have enough computer power spend more and more time waiting for their systems to finish work or struggling with messages that protest, accusingly, "out of memory"."

It's hard, too, not to warm to parts of "Decline and fall of the American programmer" (Edward Yourdon, 1993) even though Yourdon gets dangerously close to the dreaded "paradigm" word in referring to Thomas Kuhn's classic study of scientific revolutions: "If the software engineering methodology created by the young revolutionary succeeds, it displaces the older methodologies because it is seen as an effective solution to problems that [they] did not solve. Success not only improves the overall state of the industry, but brings fame and fortune to the consultant who created the methodology. No longer is he [sic] called a consultant; now he is a guru. He hires disciples to spread the methodology far and wide through the land of savages; he writes books — many books — to document the methodology in as many ways as he can imagine..."

I was taken, too, with the concept of a "net-negative producer": someone who introduces so many defects into the software he or she develops that he lowers the productivity of the entire project team. If such a metric could be introduced in the proper cultural environment, the discovery of the 'negative producer' could point the way to additional training and assistance, or it might indicate that the person is better suited to an activity other than writing code...

Which brings me to Henry Petroski's "To engineer is human". I actually bought this while on that Florida holiday that the Lab kindly helped finance back in the early days of moling. At the time, Professor Petroski was perhaps best known for having managed to write an entire book about, for all I know, with, and called, "The Pencil". Anyway, the subtitle of his book was "the role of failure in successful design", which appealed to my sense of whimsy (the only sense I have these days). "The computer is both blessing and curse for it makes possible calculations once beyond the reach of human endurance while at the same time also making them virtually beyond the hope of human verification." The book is actually worth getting just for Petroski's splendid capsule history of the fate of the slide rule.

On a slightly less esoteric tack, how could anyone resist "Fad surfing in the boardroom" (Eileen C Shapiro, 1996) which, from its very first quote ("Thinking is the hardest work there is, which is probably the reason why so few engage in it" [Henry Ford]) is a guaranteed two or three chuckles and one laugh per page? Does "Total Quality Mayhem" ring any bells? She refers, for example, to the 1980 Harvard Business Review article called "Managing your boss" (Gabarro and Kotter) in which the authors argued that effective managers "take the time and energy to manage their relationships with their bosses". Thirteen years on, this article has been re-issued as an "HBR Classic" and Shapiro notes that "skilled insiders have always been extraordinarily attentive to managing the people who control the rewards and punishments, well beyond what [the authors] proposed and not always to the benefit of their organisations".

So that's where I've been going wrong all these years...

And, speaking of stumbling, I stumbled across "Digital Woes" by Lauren Ruth Wiener; the blurb promised "particularly eye-opening, guffaw-provoking reading for any manager who has ever had anything to do with the design of a software project..." Well, I've never had to manage a software project, but I've worked on them, and I've tried to document them. "The depiction of the haphazard and fitful way software development really works — as opposed to the delightfully linear model of how it's supposed to work" — is "guaranteed to bring on the shock of recognition" according to one reviewer. Like the computer at the Bank of New York that, in November 1985, began overwriting data on government securities transactions.

In the 90 minutes before the bug was discovered (!), the bank owed the Federal Reserve $32 billion without knowing who had bought what securities, and it ultimately lost $5 million in interest on an overnight $23.6 billion loan it had to take from the Fed, pledging all the bank's assets as collateral. Or, given that this is not only the season of goodwill, but of 360 degree input and review, her item on team working: "The tug-of-war between the need for an individual contributor and a team is always present. Software that reaches the market today is commonly the product of a team. Just as commonly, key portions of it are the product of one individual: a major contributor, a designated hero, a high-status, well-rewarded person of stunning competence who put in completely insane hours for as long as it took."

Gosh, where is everybody? Must be time to go home. What? Is it Christmas? Well, I never had time to read the memo.