Frivolous Friday, 04.02.2010: I/T irony

Working in information technology typically runs a bit more smoothly if you have a developed sense of humor. Okay, maybe gallows humor, but humor. It occurred to me this morning that if you stick around long enough, you should enjoy the beneficial side effect of a healthy inoculation against irony. Here a are a few reasons why:

When you read books like L. Sprague de Camp's "The Ancient Engineers" or Frances & Joseph Gies' "Cathedral, Forge & Water-wheel," you're struck by how many technologies were born as the toys of kings & emperors. (Astrology, for instance, eventually moved beyond fortune-telling or personality assessment to revolutionize our concept of the Universe.) In contrast, "modern" computers were developed for naval ballistics and core business functions such as accounting and payroll. Nowadays, conventional wisdom is that computing's envelope is being pushed by gaming and pr0n.

Microsoft based its fortunes on an operating system--i.e. a mechanism for managing files and running applications. Three decades later, Windows XP can't delete a zero-byte file without the notification icon hanging until I'm annoyed enough to click "Cancel."

And while I'm picking on Microsoft, there's always Bill Gates at the center of an urban legend that has him proclaiming that "640 kilobytes should be enough for anyone." Windows 7 requires over 1600 times that--over 3200 if the processor is 64-bit. The much-despised Vista's--widely panned for its bloatedness--had half memory requirement (512MB for the Home version; 1GB for everything else).

The popular image of the Mac user is still the free-spirited artist, despite the fact that Steve Jobs' design dictatorship is largely celebrated as a virtue.

I was testing the battery life on a brand-new netbook by keeping it on the kitchen counter as I worked on other things. "Are you storing your recipes on that?" my husband snarked in reference to the history of personal computing.

This isn't an original thought, but as long as we're on the subject of PC history, remember the prediction that the PC would be as simple to use as the telephone? Now whole books are published on the subject of how to use name brand smartphones.

The reason that the telephone was the model of ease of use in those days was, of course, that it had to be simple enough for your Mom & Grandma to use. Now, I'm sure that there are any number of exceptions, but I'm willing to bet that most of us who do informal PC support would much rather troubleshoot for them than any number of other "adults" we could mention. (Why? Because Mom & Grandma can be trusted to follow directions. Heck, Mom & Grandma probably even read the manual cover to cover, thus sparing us a goodly percentage of the calls we would otherwise have fielded.)

There are roughly one billion people online, yet certain oppressive governments [insert scowl in the direction of Beijing], corporations and loony-tunes fringe movements somehow believe that they can sway the discourse by creating fake identities and astro-turfing.

Cookie vs. dough

Earlier today, I was thinking that applications (job applications, college admission applications, etc.) exist to establish a baseline--a lowest common denominator, if you will. But then I realized that it's usually more insidious than that. Applications are merely cookie cutters that define the bounds of critical evaluation--and figo to anything outside that.

The problem with cookie-cutters is not so much that they set a minimum standard as they give too much latitude for ignoring any dough that happens to fall outside the prescribed shape. If--and that's a big "if"--the organization is exceptionally self-aware, the "cookie" merely defines the present; it's the quality of the dough (inside and outside the lines) that shapes the future. Never lose sight of that.

What they don't teach you about product life cycle management

I had to backtrack on some code earlier today, owing to two design decisions shrouded in the mists of project history (i.e. pre-dating my watch). (The fact that one of these was both mind-blowingly stooopid and the handiwork of a self-proclaimed database guru didn't sweeten my temper.)

But one thing that I was certainly not including in the project scope was any change to the underlying database structure. And it had to do less with how things were supposed to be done than the realities of client relations. See, when your management has stooped the the level of even trying to dodge paying the base subscription fee, you can't can't consider yourself a "trophy client" anymore. Which means no more meet-n-greet trips out to your facilities on our dime. No more starting projects before the work authorization is even signed. And certainly no more freebie work, whether to humor you or enhance the infrastructure for the long term. To belabor the point, replacing relationships with transactions has consequences--and some of them I have absolutely no say in.

And I hate-Hate-HATE that! It affects the people who have to use this software day in and day out. People who are too contientious (and, frankly, just too darned decent) to deserve anything but top-drawer service. You can't even make the argument that Accounting doesn't have a line-item for such things. Intangibles such as "goodwill" and "brand equity" are certainly a factor whenever businesses are purchased.

But apart from that, I'm annoyed to discover yet another deficiency in my programmer education, which neglected to mention the impact of the client relationship on the software life cycle. And I think it brings home the point that when you pretend that no value exists outside of the bottom line, you lose more than you could ever possibly gain.

Judging a product by its documentation

A possibly disjointed post tonight, because Her Royal Kittehness is coming off anesthesia and I need to keep an eye on her. The documentation from the vet said that she might show less activity and appetite during the next few days. They lie. I've had to chase her away from the trash (which might, you understand, contain tasty butter-stick wrappers to lick) twice so far. Affection from her "hoomin" is a poor substitute. The ten o'clock feeding/medication will be a long time coming...

So I'm hoping for better luck with the documentation for haXe, which was brought to my attention by a pod-mate this morning. For the non-programmers, the premise of learning yet another language (haXe) gives more proverbial bang for the buck by allowing you to compile your source code into multiple languages: Flash/Flex, JavaScript, C++, etc. The documentation's just a small notch below "polished," which nevertheless puts it well into the upper percentiles of quality relative to that of its peers.

What really raised my eyebrows, however, was this little nugget from the project's home page:

1. Discover - Discover what haXe is about, how it works and how it could be useful to you.

"...how it could be useful to you": What a refreshing attitude when programming language comparisons so quickly seem to degenerate into spitting matches. No, I take that back. Spitting would be too adult. Make that "booger-flicking contests." Granted, I'm less than qualified to give an opinion on the completeness of haXe's features, the quality of its performance, or the reliability of its compiler(s). But I do know that it's a relief to be treated as a discriminating programmer, rather than another Kool-Aid-swilling acolyte. And I thought that deserved a shout-out.

Measuring metrics

A cynical thought from last week: In times of economic uncertainty, it should be technically impossible to go broke selling metrics. Namely because metrics bring back the sense (or, perhaps more likely, illusion) of knowledge, and with it the illusion of control. Problem is, to measure the metrics, you need more data, particularly contextual. And data tends to exist in inverse proportion to uncertainty, cancelling out the desperation driving the "need" for metrics.

Don't get me wrong: I'm not necessarily knocking all metrics, although I fervently believe that anyone who manages by them forfeits her/his title to "leadership." But I do view them with the proverbial jaundiced eye, and the foregoing is a good part of the reason.

A thought on cross-pollination

Today was the annual meeting of the Wisconsin Honey Producers Association's Western District. The guest speaker from the WI Ag. Dept. asked for a show of hands to get a sense of how many "new beekeepers" were in attendance. Dennis's hand and mine went up--we're just starting our seventh year, which makes us n00bs by comparison to most folks there. But so did the hand of one of the "old timers." Somewhat in jest, certainly, but a recognition of the fundamental truth that if you aren't learning something every year, it's time to retire.

So it was a little depressing when, in conversation, one of the folks present complimented the vitality of the La Crosse Beekeepers and followed it by noting that the beekeepers in his area operate in a spirit of mutal distrust. I sincerely hope that he's just had the (temporary) misfortune of running into one or two bad specimens.

Better yet, I more fervently hope that he will realize it and launch a beekeeping group with those who aren't paranoid. Because beekeeping operations of any scale have many enemies: Pesticides, foreign honey dumped on the market, adulterated or purely fraudulent products, drought, antibiotic-resistant diseases, devastating parasites like the varroa mite, bears, and the incompletely-understood phenomenon of colony collapse disorder. Unless they're actively destroying your hives, equipment or customer relationships, fellow beekeepers emphatically do not rank within that list.

Fortunately, the awesome peeps in this area aren't shy about sharing what they've learned, what they're currently trying, and what they don't yet understand. As I semi-joked to my district-mate, getting some of us to shut up might just be the tricky part. Here we understand that, economically, "live and learn" takes the proverbial back seat to "learn and live." Reading books and trade journals is good, except that honeybees don't necessarily consider themselves obligated to conform to laboratory or academic expectations. And the bees themselves can only teach so much: It's not like they bring back gossip about how other hives and honey-houses are being managed. The only remaining option is to talk to the bees' humans, and thereby ditch the bogus mindset of playing a zero-sum game.

- - -

Full disclosure: No one saw fit to nominate any replacement officers, which effectively continues my regime as District Secretary. Tremble, all ye keyboards!

Context does matter

It turns out that I was misinformed about the reading assignment due Tuesday. The public library does not have the book. Neither does the dead tree store out at the mall. But by the magic of the internet, I can have it near-instantly in digital format. Imperfect magic, but I won't bore you with my tribulations with Barnes & Noble online.

I'm too much a tightwad to spring for a Kindle or Nook just yet, so the only option is to download a reader application for the PC (there being no Linux distribution, thank you very little!). The software leaves any number of things to be desired: For instance, its window cannot be maximized (thereby allowing more text per horizontal line). In fact, if I try that on my dual-monitor work setup, the text disappears entirely.

But nowhere is the dead-tree mindset more glaringly obvious than in the way it clings to the paper page paradigm. Correct me if I'm wrong, but when you read multi-page text on a computer screen, your instinct is probably to scroll with the mouse-wheel to keep the text at or near a certain eye-level, no? In the reader, the scroll-wheel advances the pages, not the text. Thus I've repeatedly found myself having to backtrack (thereby losing my place and the flow of the content), simply because I've been hard-wired by MS Word, various web browsers, etc., to increment rather than iterate. That, in my line of work, is a glaring usability problem--one that I'm willing to bet is a direct heir to the hide-bound mind-set driving content packagers out of business.

I'll probably manage to train myself to wait until I'm done with the entire page before rolling the wheel. Until I've finished the content, anyway. But it strikes me as arrogant of Barnes & Noble to expect such auto-re-training. Not simply the arrogance of forcing a paper-and-ink paradigm on a digital context, but also that they are clearly not eating their own dog-food at the appropriate decision-making levels. If, for instance, TPS reports were only available to B&N upper management in their reader format, I strongly suspect that a scrolling feature would become de rigeur faster than you can say "wrong cover sheet."

Now, in its defense, the reader's ability to remember my place is appreciated. And--darn their eyes!--once you have a credit card on file w/the B&N website, it's waaaay too easy to click-and-add new titles. If the company manages to scrape together enough of a clue to offer a Linux reader, I could be in serious trouble. But given the experience so far, I'm not particularly worried.