Sunday, May 30, 2010

Input vs. output accounting

I don't like to write about an aphorism for which I can't cite the source. But I was a baaaaad (recovering) English major and didn't make a note of it at the time. It ran something like, "Measure outputs and you won't need to bother with timesheets." Which, I'll admit, seemed like a good idea at the time--perhaps for no better reason than I read it on Thursday or Friday, when the chore of the timesheet loomed.

There's definitely merit to that sentiment, except that it ignores measuring inputs as well. You know, the whole "bricks without straw" business. I didn't realize that until Dennis & I checked in on the two beehives this afternoon. One hive is going absolutely gangbusters; the other's progress is more modest.

Both hives were started from packages of equal size. Both were given roughly the same amount of existing comb (as opposed to starter foundation). Both had approximately the same amount of food to help them through the fickle month of April. Neither is collecting parasitic mites on its sticky-paper. Both Queens--bless their little ovipositors--are laying eggs wherever they can find room.

By all rights, if beekeeping were a reality TV show, the second hive would be fired or voted out of the apiary or snarkily ripped a new one by a celebrity judge. Or something.

The catch is that one hive is more shaded than the other, particularly now that the red clover & other ground-cover around the cornfield are pushing two feet and the trees of the woods to their backs are in full foliage. In the cooler parts of the year, bee-power expended on keeping the hive--particularly the brood--at liveable temperatures is energy that can't be used for building comb, scouting, foraging, or other productive activities.

The difference in location is something that an experienced/informed beekeeper will doubtless take into account & do what s/he can to tweak the environment. But an inexperienced beekeeper might not recognize the solar heating factor as an "input," because that's not something that s/he deliberately added or has a receipt for. In accounting terms, sunlight doesn't show up in the "operating costs" ledger, so it, in a sense, doesn't exist.

Translating from six-legged workers to their two-legged equivalents, an inexperienced or ill-trained manager could quickly do a lot of damage by blindly following the "measure outputs, not timesheets) mantra. Not accounting for all inputs--particularly if based on the corporate balance-sheets--could theoretically lead to perfectly sound employees being sacked for reasons beyond their control, while less ambitious (though more fortunately-situated) ones are retained during lean times.

Think about the person who always seems to know what's actually going down in the office, plant, etc. and has saved you from being blind-sided by politics. Or the front-office denizen you hit up when you need to know who the heck knows the answer to your question. The person whose job description should be "Minster of Other Duties as Required." The person in customer support who's been around long enough to answer questions about products that--officially, at least--they are no longer supposed to support.

You and I both know how important those folks are. But firing or penalizing them for "less" output does serious damage to the organization as a whole. That will show up on the bottom line, except that there will be no account to which the loss can be charged. And, thus, the root problem will likely not be addressed--at least not by the paint-by-numbers management.

In other words, if inputs are not as accurately and rigorously measured as outputs, the wheels start to fall off the concept of replacing timesheets with units of output. At best, the organization will create a monoculture of folks who won't do anything outside their job descriptions. At worst, the resulting organizational friction will clobber profits, and possibly drive away customers as well.

But, then, I suppose that basing management off a single aphorism you found on the internet is just begging for trouble.

Saturday, May 29, 2010

Mapping the world makes it flatter

(No, not because three dimensions have to be translated into two, either.)

Backstory: Dennis & I are scoping out the kind of vacation that doesn't have a "base camp" for the duration. It's more like a series of bivouac points. But we're talking the kind of places that have a single stop-light. Places that, fifteen years and more ago, would have rated a sentence in a tourism brochure. Maybe. The result was a world that pimped gimmicks in lieu of embracing quirkiness.

Welcome to the world of Google Maps and Google Street View. Of community websites and Wikipedia. Of travel blogs and TripAdvisor. In short, welcome to a world where marketing budgets and brochure space limitations just don't matter. Where the would-be visitor can (and should) use their fingers for query-typing and mouse-clicking in lieu of crossing them for luck when they roll the bones with their vacation budget.

And, while I detest the Flat-Earther mentality all the way down to my toenails, I'm down with living in a world flattened by information.

Friday, May 28, 2010

Frivolous Friday, 05.28.2010: Software superpowers

A bug report from the new QA person came back with four issues. One was a simple misunderstanding of what was supposed to be promoted up the server food chain. One was a matter of a file not being promoted. The other two I couldn't reproduce for the life of me, not even when replicating the login. So I clarified the one, fixed the other, and asked the new person to clear the browser cache & give it another whirl. Failing that, he was of course welcome to invite me over to watch him re-create the issue.

In the name of fairness, I did warn him about my on-again-off-again superpower, which is the ability to make bugs disappear by the simple expedient of standing in close proximity to the miscreant software. (I'm fairly certain that it's a holdover from doing application/desktop support where the gremlin would skip town before I was out of my chair, down the stairs and standing next to its victim.) As superpowers go, it'd be infinitely better if it were more reliable. If it worked remotely, it'd be completely awesome.

It's a given in the comic book world that superheroes aren't given a choice about which power they have. In the end, it all boils down to genetic or circumstantial crap-shoot: Jor-El deliberately chooses Earth for his son (Superman); Spiderman is bitten by a radioactive arachnid; Mr. Incredible & Elastigirl are just begging for trouble when they mix-n-match zygotes.

But if we lived in a world where one was allowed to choose superpowers, I can think of a few I'd take before the one I've been given. Of course, the obvious ones are invisibility (particularly at review-time), time-travel, a Tardis-cubicle, Jedi mind-tricks ("This isn't the design you're looking for. I can go about my business.") & the like. But here's a taste of the more obscure ones I have in mind:
  • Google-fu. Better yet, through Blackle. Then I could call myself a Blackle-belt. [rim shot]. Think about Bruce Lee, David Carradine, Jackie Chan, Chow Yun-Fat--you name it. What I'm talkin' about is the chick/dude who trained them. You know, the one who gets to call everybody "grasshopper." That level of Google-fu would make my life soooo much easier.
  • DLL/EXE/BIN X-ray vision. See, management is prone--albeit not always terminally--to thinking "If we can buy or download this software, we don't have to invest any developer time." In reality, that can be light-eons from the truth. To contextualize: Imagine your parents arranging your marriage to someone you've never met & whose family you've never even heard of. Someone who doesn't vocalize their feelings all too well. That's what the experience feels like. In such scenarios, you barter time & emotional scars for precious insight. As always, "free" has a price-tag. It would be considerably cheaper if I could peek into the clockwork of third-party software.
  • Priority-prognositication. Maybe this wouldn't be so much a super-power as a Q-caliber gadget. My mental image of an organization's priorities isn't far from a Galileo thermometer. Substituting priorities for temperatures would save untold effort, time, annoyance and office karma.
  • Intelligent Data-schlepping. Ideally, this would involve having retractable USB jacks under your fingernails. One jack is plugged into the source computer, the other into the destination. The brain cherry-picks which data actually flows between source and destination with 100% accuracy. In Star Trek terms, this would be a katra-transfer that allows you to filter out the all the annoying personality quirks. As much time as the hoop-jumping of SVN merges & SQLExaminer siphons from every single week, this is a superpower I can totally get behind.
  • Meeting-doppelganger. Maybe not a superpower so much as a creature from folklore (or D&D--your call). Except that the doppelganger transfers its synopsis of the meeting into your brain and its (copious) meeting notes to your workstation before disappearing into whatever dimension it occupies between meetings. Oh, and during the meeting, it knows which questions you'd want to ask. Who couldn't use that, I ask you?
  • Error-message Zen. There is actually a decoder ring for error-messages. It's called "the internet." What I mean is the ability to decode the actual error...not what the software in question is complaining about. As with people, these can be two completely different--yea, even diametrically opposed--things. I think that the usefulness of such a superpower pretty much speaks for itself.
I suppose that the solitary upside of not being a superhero at the superpower buffet is that I don't have to make the choice. That's not to say, though, that I wouldn't put up with an evil nemesis (or two) for the chance.

Thursday, May 27, 2010

Commando-cleaning casualty

Ever been in such a rush to clean the apartment/house/dorm up that you were too effective in getting stuff out from underfoot--meaning that you couldn't find anything you needed later? How many times did you go to the usual place to find something in particular before you broke down and went on closet-safari until you found it?

The sad thing is, this can happen in programming as well. In the process of cleaning completely extraneous/pointless variables from a web page (and herding most of the variable declarations into one place b/c they were sprinkled ad-hoc throughout the page), I accidentally made a function variable global. A recursive function variable, no less. Whoops. (If you have no idea what that means, suffice it to say that the web page basically freaked out for no apparent reason.)

Problem was, during debugging I utterly missed the fact that the (misplaced) variable declaration had moved, simply because I was so darned used to seeing it in its rightful location. By all rights, the (figurative) head-banging and ultimate forehead-slap should have registered on the Richter Scale.

All of which demonstrates that the line between maintaining good (code) hygiene and commando-cleaning can sometimes be only a few pixels wide. Just like in regular life.

Wednesday, May 26, 2010

Aggregation vs. validation

I'm glad that that I've been seeing the sentiment "You're entitled to your own opinions, but not your own facts" cropping up in my online wanderings lately. Mainly because it's a tiny glimmer of hope that folks might be developing a (justifiable) intolerance for a world where the ephemeral fads of celebrities trump years--if not decades--of peer-reviewed science. It can't come too soon, as mainstream news-reporting and, to a degree, political leadership seems, in an alarming number of cases, to be abdicating responsibility to crowd-sourcing.

Apart from the obvious consideration that crowds (in the flesh or online) are notoriously fickle and prone to stampeding in the direction dictated by the loudest--and too often least reasonable--voice, there's no room for nuance. Because, for all the talk of a semantic web, it's just that--talk. Even controlling for sock-puppets, trolls, comment-spam, respondent self-selection, etc., no software in the world can detect sarcasm, irony or satire. Let's face it, there are too many times that political/social reality and The Onion have been virtually indistinguishable.

The bottom line is to never mistake aggregation--collecting information--for validation--verifying that the data back it up.

Tuesday, May 25, 2010

It's code ownership when...

...you're the one checking the website after 10pm to verify that the database upgrade didn't break anything. Because the client has your personal cellphone number in the event it did.

I'm not saying that I don't believe (strongly!) in project cross-pollination. But ultimately, anyone with minimum training can read tombstones; knowing where all the bodies are actually buried...that's another story. So the 10pm touchstone makes for a solid reality-check amid all the theory about team dynamics and leadership and methodology and such.

(It's 10 o'clock: Do you know where your developers are?)

Monday, May 24, 2010

User-herding

The software I'm fighting tonight gives no reason for the error messages it's generating...or, rather, the real reason for the errors. What it says is wrong and what's actually wrong are two different things, which I can confirm both via the web interface and the database.

Unfortunately, consulting such "Help" as there is has long since been an exercise in learned helplessness. So far as I and the algorithmic alchemy of Google know, my version's Help was taken offline, to be replaced by the Help of the newest version. Never mind that the user interface has been extensively overhauled in the interim.

Yes, I realize that sooner or later it makes less than no sense to support versions that might not survive evolutions in platform. Or that really crufty code could leave the user (and, to a certain extent the developer) vulnerable to viruses or other malfeasance. But abandoning users one version back? Who might have darned good reasons for not living on the bleeding edge?

To me, that's mind-blowing. Partly from the standpoint of, well, it's just rude, but also because there is absolutely no gain from doing that. I mean, it's not like older Help files have to be put out to pasture with their very own domain and hosting. The space they take in the existing hosting environment should be negligible. (In fact, if user forums are the main source of support, you can pretty much bet on losing more space to the questions than the answers will ever require.) Moreover, no one expects the old files to be updated once the new version is crowned, so it's not like precious time would be siphoned off for keeping the manual springtime-fresh.

But in the meantime, legacy users--you know, the ones who cost you less to please than potential users--have been informed in no uncertain terms that they will ride with the vanguard or be left for the bandits and wolves to pick off. Now, I don't like to use the "herd" meme, because it implies slow-moving, slower-witted livestock. But the makers of the software I'm working with apparently don't even that high of an opinion of their users. And I fervently hope that they don't actually believe that they're not encouraging any evolution in their customer-base.