Life imitates art, and vice versa, but the ways in which it does so are sometimes a little surprising. There are a surprising number of parallels between what I’ve experienced working in the technology industry and what we’ve seen in a variety of Monty Python skits.
Don’t believe me? Here’s the lessons the computer industry – and perhaps your development shop – can learn from the masters of the silly walk.
The Spanish Inquisition
Be Prepared For the Unforeseen: No project ever runs according to schedule. The bigger a project, the farther off schedule it will be by the time you get to the end of things.
Anyone who’s spent any time on a software development effort of any particular size can attest to the truth of this. It’s impossible to anticipate the problems you’re going to hit on a project, and if you’re not prepared to work on the stuff you weren’t prepared for, you’ve got a problem. Sometimes a very big problem.
Not having the slack to pick up the unexpected was the death (not too soon) of the first attempt at writing a replacement for Mac OS, Copland. Copland was, at its heart, an effort to sort-of kind-of graft memory protection and real pre-emptive multitasking onto the “classic” Mac OS platform. The brilliant people in charge were pretty sure this was going to be more-or-less a slam-dunk—even while in the midst of changing processor architectures—and when it turned out to be a lot harder to do than to plan to do, the response of the engineering team was less than resilient. (It turns out that “Getting Hit On the Head” lessons do not speed up software engineering efforts. Go figure.)
For extra credit, the beginning of this sketch serves as a good warning against the overuse of jargon, another sin to which we’re prone: “It seems that one of the flayrods has apparently gotten out of skew on the treadle” isn’t terribly helpful information to anyone.
And, too, the sketch illustrates how a project can get off track from the dreaded off-by-one error. (How many weapons do they have?)
I’m Not Dead!
Know When You’re Dead: The truth of this Monty Python sketch was brought home to me, pretty forcefully, by two recent developments. First was the wholesale capitulation of Nokia to Microsoft. The second was the subsequent “I think I’ll take a walk!” optimism coming from the suddenly-abandoned MeeGo (which needs to be renamed “MeeGone”) stalwarts—after all, when you’ve got good enough software, who needs hardware to run it on?
Nokia spent far too much time pretending that there was still some life in the Symbian platform, long after it was apparent to anyone with the slightest bit of sense that they couldn’t compete with iOS or with Android. The much-vaunted effort at a touch-based version of Symbian, the N97, was a pretty-universally acknowledged disaster. Instead of having two large, space-wasting buttons to choose between (over and over), you have two large screen-wasting buttons. By the time the fantasy that Symbian could still be the basis for something came to a dead stop, like a sort of slow-motion train wreck, the only choices left to Nokia were “bad” and “worse.” At least they got a billion dollars out of Microsoft for their troubles, but it’s still got a strong flavor of the Titanic forming a strategic business alliance with the iceberg.
The Dead Parrot
Don’t Deceive Your Customers: This is the “outward-facing” (as marketers like to say) corollary to the preceding point. We work in an interesting industry, where it’s possible to raise millions on the strength of a rumor. Vaporware is a fact of daily life, and it’s been claimed that the specific road to Hell which is paved with good intentions is Sand Hill Road, over in Menlo Park.
One of the best industry stories of outward-facing industry deception is the tawdry history of Gizmondo, a much-touted handheld gaming console. On the strength of a concept, Swedish gangster Stefan Ericksson managed to get himself a million-pound salary, a £5,000 monthly car allowance, and a variety of other perks that allowed him and his cronies to burn through almost $300 million in funding raised on the sale of stock in the company. By the time the product hit the market, the reality turned out to be substantially less than the hype, and fewer than 25,000 were sold. The company quickly went bankrupt.
Mr. Ericksson is, perhaps, most noted for having survived what might possibly be the most expensive single-car crash in recorded history, in which he literally bisected a Ferrari Enzo, with a street value of about $2 million, after bouncing off an embankment in Malibu at hitting a pole at an estimated 162 miles per hour.
Making claims for your product that don’t hold up in real life is a sure recipe for disaster. Are you claiming to teach people How Not To Be Seen?
Mr. Creosote – Monty Python’s The Meaning of Life
“More” is Not the Same As “Better:” For years, the mobile phone industry — as typified by OEMs like Nokia and Motorola — marched along to the beat of the carriers’ collective “standards and requirements,” which essentially amounted to an extremely lengthy checklist of mostly extreme minor features, quibbles, and quid pro quos. In the case of one major carrier, the requirements specifications stretched to some 1,800 pages.
Apple turned that all upside down with its introduction of the iPhone, which failed to implement even such commonplace features as MMS messaging. Predictions of imminent doom for the device and for AT&T (the carrier foolish enough to go for an unproven phone from an inexperienced manufacturer) were rife (and I admit to being among the misguided doomsayers, initially).
It turned out that consumers didn’t care about the carriers’ checklists, and they pretty much didn’t care about niceties like MMS messaging, either. What they did care about was nice design and thoughtfully constructed — both surprising and consistent — user experience.
Adding features aimlessly guarantees that none of those features will be thoughtfully implemented; it reduces the likelihood that any of them are well-integrated. Worse, just-one-more-feature considerably increases the chances of the unexpected happening to your project (see point 1).
Product marketers love to try to squeeze just one more tiny feature — really, it’s wafer thin! — into everything they work on. It’s a bad idea.
The Argument Clinic
How Not To Communicate: We have a strong propensity in the computer industry to not only argue, but to argue about what we’re arguing about. Most meetings are, in fact, meta-arguments, which explains why everybody loathes them.
Not only do we argue with one another, we argue with our customers, or at least our potential customers: If you don’t think our product is awesome, you must not be smart enough to appreciate it! This tendency is perhaps most easily spotted in the free and open source software community, which is sort of a shame, really. Many people are initially enticed by the prospect of a free (as in beer) operating system — who really wants to pay big bucks for Microsoft Office or iWork? — but heaven help them when they find themselves stuck on something, and think that they’ll go ask the “friendly community” for help.
All too often, the friendliest advice they’ll get is “RTFM,” and much too frequently, they’ll be derided as “clueless noobs,” or “not smart enough to use Linux.” Anti-marketing at its best.
As we can see, Monty Python has a lot to teach us about how to work more effectively in the technology industry. Projects would go more smoothly, customers would be happier, products would work better, and we’d be laughing all the way to the bank, instead of at the last “little feature” our product marketing lead told us we need to slide in at the last minute.
