So, I’m a computer programmer. I think I’ve mentioned that before.
And today, I experienced the very bane of a programmer’s existence, the one thing that will wake a coder up from a dead sleep, shivering and sweating and trembling like a junkie just at the thought of it.
(Well, the ‘one thing’, assuming you’re not counting any of those Lara Croft dreams. Those’ll get you, too. But that’s different. Not so scary, and way more exciting, and often far, far messier. But different, is all I’m saying. Baby can raid my tomb any day of the week. Ahem.)
Anyway, if you’re in software development yourself, then you know exactly what I’m talking about — the demo. The presentation, the rollout, the dog-and-pony show. It happens all the time in the life of a software engineer, and there’s absolutely no way it can go well. None. Never happens. Like Oprah walking away from a jelly doughnut. Not possible.
For you see, there are only two potential outcomes from a software demonstration, and neither of them bode well for the person or people who actually worked on said systems. The first — and far likelier — scenario is that something goes horribly, horribly wrong in the course of the demonstration. Maybe the network fails, or the hard drive poops out, or some idiot (who’s likely giving the presentation) accidentally left the test code in the system that prints out, ‘The boss blows fuzzy llamas!‘ when a function is working.
(What? No. No, of course I’m not speaking from experience on that one. I would never put such a thing in my code, even as a temporary diagnostic. That’s just wrong.
Or so my last termination letter would have you believe. But hell, what did that guy know? He blew llamas. And fuzzy ones, at that. Who is he to tell me how to live my life?)
Anyway, in most cases, the software demo blows up at some point — a link breaks, or the app crashes, or the machine starts spewing smoke through the floppy slot. (Heh. He said, ‘floppy slot‘. Heh heh.)
And that’s not good — it makes the coder look bad. Sometimes, it makes other people look bad, too. And the more demos you give where you’re left stuttering and sputtering, with a fire extinguisher in your hand and a program that refuses to function, the less faith people have in your next show-and-tell extravaganza.
(I always heard that people have short memories, but in the software world, that’s just not true, dammit. You’re only as good as the last thing you built that didn’t catch on fire, basically. For me, you’ve got to go back to 1995 for my last real success. I wrote a script to print out the current time every twenty seconds. It didn’t do much, but that little fucker worked, you know? And for all I know, it’s still going. Kick ass, little time-printer-outer thingy! You’re all that’s kept me going, lo these many long and shamefully embarrassing years.)
But as bad as a miserable software failure in front of your peers, colleagues, and the people who write your paychecks is, it’s absolutely dwarfed in negative significance next to the alternative: unmitigated, smotth, clear success.
For you see, it’s well known around the software world that every demo given is to be comprised chiefly or entirely of vaporware. In other words, programs and systems that could exist, one day — and maybe even some that should exist now, if you believe what certain project planning documents tell you — but do not, under any circumstances, actually exist in the world we live in at the moment. If you can dream it, you can demo it — that’s our motto. Actually building it… well, that’s a whole other twisted mat of pubic hair that we’ll have to untangle when we get to it. Whether such a thing is actually possible to build is really quite irrelevant to the demo — it exists on a different plane of reality, where all the data is made up, and all the requests take only milliseconds to process.
And all of that would be well and good, but apparently — inexplicably, maliciously, and irresponsibly — no one actually tells the non-technical folks in attendance at one of these demos what the score is. And so, after one of these ‘successful’ demonstrations, you end up with poor, misguided souls who firmly believe that everything they’ve just seen has already been thought out, put into place, and is just sitting there, tapping its little digital toes, waiting to be used. These poor bastards plan on using the system they’ve just seen, and document how they’ll use the system, and even encourage other people to use the systems — all without ever realizing that the ‘system’, as they call it, is no more than a pretty pageful of fake data and a flashy icon. The ‘system’, as understood by the user, would take twelve years and the gross national product of a large Scandinavian country to construct, and might actually require bending, or even revoking, a couple of Newton’s Laws of Thermodynamics.
(For the record, usually the Third Law, and sometimes the Second. The First seems to be less of an issue. Oh, goody.)
And that’s the kind of demo I had today. It was part of a larger talk, so I only did my thing for five minutes or so, but it went off just about flawlessly. Everything worked, I managed to explain the rationale behind the changes, and the entire audience patiently listened and watched as I talked about, then showed, live and in person, the changes that had been made. They didn’t applaud at the end of my segment, but they seemed quite happy and impressed. Clearly, this system is going somewhere, and the users are on board for the ride.
See, that’s the last thing I wanted, dammit. All I need is a gaggle of drooling users to get behind this shit, and convince themselves that the whole damned thing is working already. Software demonstrations are like minefields — on any given screen, there are dozens of links and actions that could send the whole thing up in smoke; the true art of a demo is to navigate those treacherous waters, using only the functions that you’ve frantically fixed that morning, so they’ll work for the stupid demo. It’s magic!
But no one outside the development team seems to understand these rules of engagement, when it comes to new software. At a demo, anything that doesn’t explode in flames is automatically assumed to work beautifully. And what you can convince them isn’t quite already ready is assumed to take ‘two weeks’ to complete. Everything’s ‘two weeks’, when they’re telling you what needs to get done. Two weeks, two weeks, two short frigging weeks.
Anyway, all of which is to say, I’m pretty much bent over a chair at work for the next little while. The demo kicked ass, and now people are starting to ask questions, like ‘is it really always that fast?‘, and ‘I thought that bit was physically impossible?‘, and ‘How can I get my grubby little paws on this thing, anyway?‘ Meanwhile, the ‘system’ itself is just a figment of my fevered imagination, the way things ought to work, if only we weren’t bound by such trifling nuisances as a limited budget, finite space, and the speed of light in a vacuum. It’s that teeny little disconnect that gets you in trouble, you see.
Eh, screw it. I’m goin’ to bed. I can’t go back and sabotage my own demo, so I guess I’m just gonna have to live with the unreasonable expectations that I’ve foisted onto myself with a demonstration of the new ‘system’ this morning. I’ll worry about that nonsense tomorrow, when I’ve had more time to cook up excuses as to why the thing will never work the way that they really want it to. It’s all about managing expectations, folks. I’ve just got to set the bar sufficiently low enough that I can still slither under it, and everything’s gonna be just damned peachy. So, I’m hitting the sack. And maybe, just maybe, if I’m lucky, Lara Croft will be there in my dreams, showing off all the bells and whistles of her own brand of ‘vaporware’. Ah, sweet sleep, where is thy sexy sting?Permalink | 2 Comments