What elephants can teach us about software development

There's a fable from India that has a various number of people (usually six) encounter an elephant for the first time, and they are either in the dark or blind. Each person happened to touch a different part of the elephant before s/he walked or was led away. Thereafter, the people variously claimed that the elephant must be like:

• A dried-mud wall (its side)
• A great tree-trunk (its leg)
• A sword (its tusk)
• A butterfly (its ear)
• A snake (its trunk)
• A rope (its tail)

The fable has been interpreted as a warning against arguing with only partial understanding, and also the pointlessness of arguing theology. But it's not a bad lesson to keep in mind if you ever have to take over a software project originally written by someone else. In that case, you can put out your (metaphorical hand) to make your judgements based on things like:

• The code
• The database structure
• What the screens look like in The Real World
  
• How it fits into the organization's priorities, processes and politics
  

As with the elephant, each aspect of the software gives a completely different impression of how the software actually "works." None of them is to be relied upon. As a programmer, it's tempting to think that once you've wrapped your brain around the first two, understanding is a done deal. Yet the projects where I've been able to shadow the users and to actually (ab)use the software on a test system have generally be the successes (local politics permitting). I've been pretty lucky, because that's been the norm rather than otherwise. The other situations, however, have typically been pretty rocky experiences for all involved.

In other words, if programmers asking questions of real, live users is "a waste of time," I have no pity to spare for the time wasted on software re-writes and any collateral damage caused by deadlines being missed. Because, to a degree, each one of us is feeling around in the dark. And while we most often have to make decisions with incomplete information, only the fool is certain of her/his understanding.

- - -

See you on January 2nd, folks. Cheers and thanks very much for sharing 2009 with me!

Instructive irony

Two spouses, both working in I/T as programmers for hire. One has mandatory PTO this weekend, the other mandatory overtime.

Such feast-and-famine contrasts point up one Dark Side aspect of being in the business of renting out skills/talent. Which is, of course, not news for anyone who works for her/himself and not The Man. But I doubt that the need to be as disciplined with one's cash flow as one is dedicated to one's craft figures into many day-dreams of ditching the day-job. A romance-killing thought, certainly. But not so bad as the image of having to re-shackle oneself to wage-slavery loaded with the debt from a failed business.

Noblesse oblige

Any webified software worth the name has to have some back door for They Who Know What They Doeth. It's just a given. Why? Because someone needs to make things easy for everyone else. That's the idea, anyway.

The problem (for the workaday programmer, anyway) is that now two audiences are involved:

1. Joe or Jane User
2. They Who Know What They Doeth

Yet, the project specifications are--in my relatively limited experience--written solely with Joe/Jane User in mind. You watched Pirates of the Carribean, yes? The scene where the Interceptor is trying to outrun the Black Pearl and has to throw everything that's not vital overboard and fire everything with sharp points from the cannons? That's precisely what a software deadline is all about.

So when it comes to the choice between smoothing the experience for the customer and saving They Who Know What They Doeth a few clicks/keystrokes, it's the customer who always comes first, right?

Riiiiiiiiigt?

Sadly, conference rooms can become a bit of a battlefield on this point. If you're a programmer and have to fight for pitching vital resources into the customer experience, that's probably normal. If, on the other hand, you're expected to stretch what little time's left to serving both masters, it's as good an excuse as as any to refurbish your resume. If this lack of choice is standard operating procedure for each software release (or even a simple majority of them), maybe it's time to release that resume into the wild.

Mainly it boils down to this: It's perfectly natural to believe that all users are created equal, no question. But the uber-users can usually be trusted to be aware of the damage they can do. Thus, bullet-proofing the system should focus on Jane/Joe User's interaction with the software, simply because s/he isn't privy to why things are done in a specific way. Trust me: It's nearly impossible to underrate the "why" of things.

But that's another touchstone: If the software development cycle doesn't allot time to make life easier for the uber-users after the customer is tended-to, that's another sign that resumes need to be floated with all appropriate discretion. I'm fortunate enough that the first responsibility of They Who Know What They Doeth is the care of our customers. And I'm more fortunate to have realized that it's a synergy to look for, should I ever need or decide to look for another employer. Lesson learned...and duly passed on to anyone who might find it constructive.

Crashing and context

Obviously, computer viruses are bad, but oddly enough, we think of something "going viral" as unqualified good. Except when it crashes someone's server and we weren't the first kid on our block to score a look-see. Which is apparently what happened earlier this month when two name brands of geekiness intersected.

Oops. (Poor system administrators...)

But that sort of thing happening once (or even once in the proverbial blue moon) definitely has some undeniable cool factor. In fact, it's more or less a badge of honor. At least for an outfit that doesn't rub elbows with the Fortune 100--or even 1000--country club companies.

Me, I think Bill Amend made the right decision not to rush out and upgrade his hosting. After all, he's responsible for a once-a-week cartoon, not Google. Because, as important as it is to know where you want to be, understanding exactly where you are is just as critical. Big ups for knowing the difference.

No official post tonight

Just back from celebrating Christmas deferred by the weather. Ergo, no post tonight, in honor of the holiday, albeit a "stunt" one.

A slightly depressing perspective

Sigh. Leave it to History--not unlike grandparents who lived through The Great Depression--to squelch self-pity, particularly the kind that has apocalyptic undertones.

Backstory: My husband and I spent our 2006 vacation in Washington, DC, partly because neither of us had been there before, and partly because one of my passions is Venetian history (particularly the Renaissance period) and the National Gallery of Art's feature exhibit covered that time period (in spades!). Like any self-respecting museum, the NatGal sports a well-stocked bookstore--actually, more than one, IIRC--which is where I scored Patricia Brown Fortini's Private Lives in Renaissance Venice.

Dipping into that reminded me that intrusive government regulation is nothing new, and that there are definitely degrees to "intrusive." In this case, the Venetian patrician class (less than 5% of the city-state's total population) prided itself on maintaining an illusion of solidarity for the lesser classes, and indeed, the world. Part of the process of maintaining this illusion was minimizing the disparity between the richer and poorer echelons in the nobility by tamping down attempts to flaunt wealth. (The history of the Middle Ages and Renaissance is rife with such "sumptuary laws," which were also intended to prevent wealthy merchants from impersonating their social betters, particularly in terms of dress. Such laws were, btw, spectacularly unsuccessful in the face of the Force of Nature that is the impulse to one-up the Joneses.)

Rationale aside, regulating what cloth could make up one's clothing or how much embroidery or lace could be added, or even what kinds of food could not be served at a wedding feast seems more than a bit excessive to our modern (and, in my case, at least, American) sensibilities.

As much I dislike making forays into the political realm, I will go on record that my hope for the option of buying health insurance from a public pool open to all (having seen first-hand what an insulting joke the options for the unemployed can be) has been disappointed by the over-compromised "solution" to the fundamental problem that Americans pay ridiculous per-capita sums for lesser health care outcomes.

But I can't help but wonder whether the solution would have better addressed the problem had some people--people who should have been well-read enough to know better!--would have resorted to constructive debate, rather than hyperventilating sloganeering--or, in some cases, pure self-serving delusion. Call me biased, but I firmly believe that a little historical perspective on "regulation" and "reform" would have gone a very long way. Venice is fascinating for her uniqueness, not least of which because she was, at the height of her power, an remarkably enlightened state built to avoid concentrating too much power in too few hands. And, significantly, her wealth and relative security made her the jewel of Europe, regardless of sumptuary laws.

Far-from-Frivolous Friday, 12.25.2009: Holiday wishes

As the various winter festivals wind down, a few wishes for this season and the year to come:

• Folks spent the winter holiday of choice with those who meant the most to them
  
• No one felt obligated to financially over-extend her/himself in observance
  
• Gifts exchanged were meaningful, and won't follow their packaging into the landfills any time soon
• Engagements contracted lead to happy, enduring marriages
• Celebratory calories consumed evaporate on the treadmill far more readily than plain ol' workaday calories ;-)
• The Great Recession of the last year+ has left a lingering appreciation of what was previously taken for granted
  
• (The runner-up) The food pantries, animal shelters and other humanitarian agencies saw a better-than-expected bounce in donations
• (The winner) No one gave the emergency rooms (or, far worse, the morticians) any business that could be avoided

And, of course, the simple wish that the world will be a better place a year hence, in the micro-cosmic as well as macro-cosmic sense.

Cheers, all!

Geeky gratitude

I'll probably be kicked out of the Geek Treehouse and divested of my secret decoder ring for revealing this, but there's this post-holiday game of one-upsmanship we computer types like to indulge in. It's based on swapping horror stories about the problems we've had to sort out in our relatives' computers. I don't get to play, because Mom really doesn't do that much with her computer, my brother-in-law isn't the type to ask for help, and Dad's a born tinkerer. It's probably just as well, because it wasn't until recently that I realized how playing the afore-mentioned game would be in poor taste--at least in my case.

See, I have the dubious blessing of remembering quite a lot of my childhood. It's filled with instances of parents putting things back together for me: Mom sewing arms and tacking eyes back on stuffed animals, Dad melting the tips of the axels on Cinderella's carriage so that the wheels would stop falling off--that sort of thing. Occasionally, scolding for my carelessness might have been involved. But never ridicule for what I didn't know how to do.

They both were geniuses to me then. And so it occurs to me--nearly forty years later, 'cuz I'm usually not that swift on the uptake--that it's now my obligation to pay that back. Or forward, depending upon how circumstances present themselves.

Hacking the hive, part II

The alpha-hacker of the local hackerspace and I were trading tweets earlier after I joked that we had to find a way to work honeybees into the place. He called my bluff, though, bringing up an idea that my husband and I have been knocking about for awhile--namely, concocting a monitoring system for the hive. I mean, there's no shortage of tragedy and misery to go around in this world, but opening a cold, damp, lifeless hive matted with bee carcasses is distinctly Not Fun. What would be useful is to be able to monitor vitals like temperature (internal vs. external) and the (internal) humidity that can doom an otherwise healthy hive. Possibly even CO2 levels besides, to get a rough sense of the airflow. All in real time.

But. There's this little consideration of data transmission, with beehives tending to be more rurally situation--not exactly optimized for broadband access. Which is more or less a deal-breaker, if I don't build on the backbone of morse code transmitted via AM signals, as Alpha-hacker suggested. Beyond transmitting the data, other requirements for that kind of setup would be:

• High efficiency circuity, ideally powered by solar-charged batteries
• Ability to withstand swamp-like humidity levels (combined temperatures that can vary between close to freezing and well into the 90s F)
• Some mechanism for encapsulation (to protect from bee/hive parasites, particulates, and the bees' own tendency to shellack any non-smooth surface with wax or propolis)
• A price tag that would make sustainable manufacturing and wide-scale adoption feasible.

That last requirement might very well be impossible, except for researchers and deep-pocketed hobbyists. So I'm not exactly rushing off to the workshop with dollar signs in my eyes.

But, technologically, we're at a stage where the pieces of this sort of application are well within reach, and need only the economies of scale to take off. I'm not necessarily talking about beekeeping, which has unique considerations. But the combination of ubiquitous broadband, miniturized processors, solid state data storage, off-the-grid power and micro-messaging (e.g. SMS) will scratch many, many itches in the next few years. That's how a jest turns into "Whoa---we could actually pull this off..." (Actually, I worked for a company that, quite literally, originated with a flippant remark. These things happen.)

Until I get off my backside long enough to decode Morse and webify the data or rural broadband really takes off, the wired beehive will not happen, at least not for our Ladykins. But that doesn't mean that it's not an awesome time to tinker.

"Signal" and "Noise" are language-agnostic

I found three different versions of the same functionality today: One in compiled code, another in web code, and the last in database code. And I only "found" the first because I knew to look for it. But...which functionality is the One True Way to Getting It Done? Good question. Somebody should figure that out and write it down sometime...*

Yes, it's probably my tendency toward OCD talking here, but there is such a thing as signal-to-noise ratio in code. (As there is with any number of other things, I/T-related and not.) And when the time can't be found to clean out the cruft (a.k.a. the noise), how can one criticize the newer team members for adding yet another version (i.e. more noise) to the code?

Remember, newbies are at a political disadvantage when compared with the Old Ones: To question is to criticize (however implicitly); to quietly choose one method over others risks offehnding those whose wrote the "runner-up" code. That is not a choice you want to present to new folks, because the proverbial path of least resistance is mimicking existing code--likely with a limited understanding of it. Which is precisely the path that you don't want them to trod.

- - - - - - -

* In truth, I'm doing a huge disservice with my sarcasm: I raised the issue, and it was addressed within the hour. No messengers used for target-practice, much less sporting powder-burns. It's one of the many joys of working with awesome peeps...for people who don't get in the way of awesomeness.

Neeeeww-speak

Clicking a link in today's Tweetstream led me to the virtual doorstep of Forbes.com, who promptly inserted an ad between me and the intended article. Granted, Forbes offered the customary courtesy of providing a link to close the "welcome screen." But it's not the ad that bugged me--nor even its insertion. (Forbes is a publication after all, one which--unlike Consumer Reports and Cook's Illustrated--doesn't consider its priorities compromised by taking advertising dollars.)

No, it's the new-speak of "welcome screen" that I thought almost insultingly lame. Could you imagine putting an ad on your "welcome mat"? How about hacking your doorbell to blare a jingle at the front step before it rings inside the house? No one would consider that "welcoming" behavior in the real world; why is the online world allowed to abuse the terminology? You're no more a "guest" on that sort of website than if someone invited you over just so they can try to hook you up with their roommate. Let's face it: there's always an "eeeeww" factor there, no matter how hawt the roommate is. Or, for that matter, how useful the article turns out to be.

The legacy of imperfection

I/T folks my age (40 or thereabouts) seem to like to swap stories about plinking away on PCs boasting a whopping 16 Kilobytes of memory and having to save our programs to cassette tapes and "chatting" from command-prompts and all that. Aside from the "bonding" it provides, the horrified looks from the "young'uns" are usually worth a laugh. But I realized today that there's another "legacy," if you will, of being exposed to computers of the pre-Windows, pre-plug-and-play era: The feeling that you're not entitled to have everything work out of the box never quite goes away. (Whether it should is another debate for another day.)

I thought about that today when I was trying to copy data from my workstation's copy of a database to one on a different machine, and my workstation's software decided to freak out every single time I tried to export the database lock, stock and barrel. No error message, just a lock up that forced me to deliberately crash my browser and log in again.

The solution was simple enough: Just export the database in pieces. In this case, rough thirds seemed work. After a quick test to prove that something in the export process itself wasn't hosed, coaxing what I wanted out of the silicon and electrons was a matter of a few extra clicks and a couple more minutes. All in all, just an exercise in rewinding my brain to a past mind-set--and by "past" I'm only going back a decade--when I wouldn't have expected my employer to provide a bleeding-edge PC, nor could I afford one myself.

As workarounds go, it wasn't even remotely inspired, and anyone--even in this age of super-sleek software--with even average persistence would have arrived at the same solution. Coming from a background where the duct tape so often showed, however, saved a certain amount of freak-out. Which is nothing to be sneezed at. Particularly when this won't be the last curve-ball thrown at me on this project.

Tool-tip

I'm working on a project that involves customizing an open source web application. The extra twist in this case is that the organization is using a previous and wants to upgrade to the latest/greatest, which hasn't officially been released yet. The changes extend to the database level, and I spent a non-trivial amount of time this afternoon trying to determine the extent of those differences.

Because the software is not considered ready for prime-time by its creators, the "upgrade" process, apparently, does not yet include the option to upgrade the database. I hope I'm wrong about that, but in the meantime I need to shoehorn the old version's data into the new version's structure.

That wouldn't have been half the trouble that it ultimately was, had I had my proverbial ducks in a row from a tools standpoint. Which, superstitiously, I almost think was an act of mooning the gremlins. Because that's when MySQL Query Browser decided to crash (repeatedly!) on a pretty boring database query. Disgruntled, I launched the bookmarked URL for it webified cousin (PhpMyAdmin), only to discover that I'd whacked it when I rebuilt my workstation. And in the scramble to bring it back online, I rushed the process, with predictable results.

Now, when you start a new job, you face a learning curve comprised of something like the following:

• New personalities, with all the tensions and synergies that this implies
• New priorities
• New product(s)
  
• New processes
• New tools--or, perhaps more likely, familiar tools (ab)used in creative ways

And on top of that, you can pretty much count on not coming on board at a convenient time to be comfortable with all of them before you're caught up in the stampede toward the latest deadline.

My not having all the tools set up was a rookie-type mistake. Freelancing (even as a volunteer) is not much different from starting a new job. The tools, at least, should have been oiled and ready to roll. Because working for someone outside their work environment means spending extra time staying plugged in to the communication channels. That doesn't leave much slack, certainly not for fumbling with the tools that should be as prepped and ready to hand as a surgeon's instruments.

Frivolous Friday, 12.18.2009: The post-Newtonian Santa

Something like a decade ago, my husband sent me an email very like "Is there a Santa? A Physicist's View." Wow, talk about a killjoy, even if you aren't old enough to work out the math for yourself.

But then it occurred to me: Why does Santa have to operate on classical principles of physics? True, St. Nicholas of Myra lived during the 4th century--well before even Newton (much less Einstein, Planck, Heisenberg, Schrodinger and company), but that doesn't mean that matter and energy operated any differently in the days when folks were still looking back to Classical Greece for their science.

Quantum mechanics--among other mind-bending principles--holds that it is impossible to verify the properties of things which cannot be measured: Everything boils down to probabilities. That enables the concept of something existing in more than one place or state at one time. And you will recall, of course, that we are never, ever supposed to actually see Santa Claus on Christmas Eve. That is a paramount tenet of Clausology. (Clement C. Moore was either cheating or lying through his teeth!) Moreover, much of quantum physics revolves around uncertainty (particle or wave? position or momentum?). Just as there is always a fundamental uncertainty to the existence of Santa Claus--otherwise, generation after generation of children wouldn't ask "Is there really a Santa Claus?"

Coincidence? I, for one, think not.

The only rub lies in the fact that by the time you're old enough to have enough physics to appreciate (even if only superficially, like I do) the differences between classical, relativistic and quantum physics (particularly in terms of scale), you're probably too old for Santa to visit any longer. But, then, you're likely old enough to be your own Santa Claus. In any case, it's not like the Universe will run low on mysteries anytime soon...

The invisible programmer

Yes, yes, yes: The stereotype says that we're supposed to be introverted and all that. And, in truth, there are days when it would be a relief to be able to lock myself and a laptop in one of the conference rooms, leave the phone off the hook, log out of IM, and feed the issue tracker's email address to the spam filter.

But that only works if whole point of the code in question is merely scratching one's own itch. Not that this is a trivial thing, mind: Just ask Steve Wozniak (the brains behind the original Apple PCs) or Linus Torvalds (the brains and charisma behind the Linux operating system). But anything written for other people, by definition, must involve them at some point. Partly for their real-world, prime-time criticism. Partly for the inventive ways in which they can abuse/break it. And especially for the always-surprising locations of itches.

Your work vs. your job

I follow @KathySierra on Twitter, and this gem rolled through the tweetstream earlier today:

@KathySierra One of many reasons I was an awful manager: I assumed everyone loved "the work", even if they hated "the job".

An interesting distinction, that--she certainly can't be accused of splitting hairs for any job I've ever held, and I suspect that's true for many, if not most. My "work," in the purest sense, is banging out code. But that can only be done in the context of my "job," which involves things like:

• Meetings
• Wiki documentation
• Pitching other people's code up the server food chain
• Spot-checking the output automated processes and figuring out what went wrong when the output is wrong or non-existent
• Doctoring data when people ignore the instructions in front of their faces and deliberately subvert checks and balances
• Scribbling what I did under each billing number every day and plugging it into the time sheet form at the end of each week
• Keeping an eye on news about the firm's industry, which has next to nothing to do with programming
• Translating--meaning explaining what an application does in the real-world context of its use, or explaining the gap between what was expected and what actually happened.

Not a lot of time wasted on politics, thankfully. Politics, to me, is a sign that the gap between the work and the job has grown intolerably wide: EPIC Management FAIL there.

But one thing that I think that needs pointing out (and not merely because Ms. Sierra only had 140 characters to work with) is that the work can suck and the job can be just fine. Retail, for instance, was something I did to pay for college & other sundries. I can do it; I'm just not natively wired for it. The semi-annual storewide sale should, by all rights, have been a nightmare on 18 wheels. But the store manager made sloppy joes that were To Die For--as we said Back In The Day--and those in large part made it worth it. Those plus the fact that the shifts certainly didn't drag.

But, that being said, the gap between work and job should, optimally, be as minimal as possible. Nothing's a sure formula--I get that, honestly. But I also think that it minimizes stress when people feel like they're doing something close to what they're "officially" expected to do. And if they're doing something close to what they're passionate about, so much the better.

Chieftains vs. connectors

Something occurred to me today during my daily "news cruise," the first stop being Seth Godin's blog. I don't disagree with his insistence on the importance of "tribes" in internet space. Being the chieftain of a tribe can be a more than full-time job--with all the frustration and fulfillment that implies--and it's drop-dead critical, simply because so few people are willing to paint a bulls-eye on their chest--which is largely what any leadership position involves. That said, being the sort of person who can connect tribes is equally critical. I have absolutely no data to back this up, but my gut hunch is that the chieftains are typically not the connectors, simply because the roles (and skill sets involved) don't necessarily overlap.

The upshot is, don't reserve 100% of your attention for the chieftains in any group; save some for those who exist in the intersections of two or more tribes. It's the difference between today and tomorrow.

"Bobby" joins the QA team

When we promote code to either the beta (i.e. testing) or production (i.e. live broadcast during prime-time) servers, standard operating procedure is to make a spot-check before turning things over to QA. Today, I pushed something into production and made a quick check to see whether an including an apostrophe in input field of a web page could cause the page to error out.

When I moved the fix onto testing, I seriously toyed with the idea of reporting that I had validated the fix with the following input inspired by one of my all-time favorite xkcd web comics:

something'); DROP TABLE zzz; --

where "zzz" would have been the name of a database table that would bork our flagship application But Good if its data were lost. (Btw: If you bring up "Little Bobby Tables" in a room full of programmers, it's pretty much a cinch that at least 3/4 of them will know what you're talking about. Most of the 3/4 will probably laugh, too.)

If the "Bobby Tables" code-snipped above looked like gibberish to you, let me break it down. It's known as a SQL injection attack, and the would-be attacker is attempting to subvert the code you intended to run by:

1. Prematurely terminating the database access code you intended to execute
2. Attempting to completely delete a table's worth of data (assuming the table name is known or can be guessed)
   
3. Voiding any additional code that you would have execute, so as to prevent it from generating the syntax error that would have stopped their attack short in its tracks
   

The sad news is that I didn't learn about all that in programmer school. The happy news, of course, is that I didn't learn it the hard way. That being said, any web programmer worth her/his keyboard knows to expect those sorts of tricks and bulletproofs the code accordingly. Of course they do. Because somehow half of everybody brags about hiring (or at least keeping) "only the best."

But. Would half of everybody be willing to have every last input field of every single screen/page of absolutely every application tested by Bobby Tables? Probably not, so it's a question that has considerable value, whether you ask it of yourself or others. For instance: I don't tend to pull my punches during job interviews, so that was just added to the quiver I'd use during the technical part. Because I'm looking for how the question is answered, more so than the answer itself. (Hint: A blank look is bad; glib assurances that "it couldn't happen" are rather worse. Ignorance can be cured. Hubris is usually terminal.)

And for anything I'd write (or manage), Mr. Tables is henceforth part of my QA team. I figure that one or two frantic database restorations (hopefully on the QA server, not the live one), is the short, sharp shock kind of lesson that will stick with a programmer for years (including me, who have already found alternative ways of hosing a database). Who knows? The lesson might even linger for an entire career, depending on how much grovelling before (or bribery of) the Sys. Admin. is required to rectify matters.

When "free" doesn't come cheap

Don't get me wrong: I truly rejoice at the acceptance of free and open source software by the upper echelons of corporate culture--it's nice to know that the hippie chick can at least give the supermodel (<- NSFW, btw) a run for her money. But I've come to suspect that (at least some of the time) the reasons for that acceptance are short-sighted. And, worse, suffer from the same false accounting that considers interaction with its customers a cost and a menial task for the least paid and least trained.

Simply put, tweaking "free" software is all well and good until you need to upgrade. Those changes accreted over the months and years to make it put the right covers on your TPS reports? Wiped clean in the tabla rasa of a shiny new installation. And if documenting those changes was considered too expensive, effette or whatever, you're in even bigger trouble. Granted, if the programming team was foresighted enough to use source control on the original code, the prognosis is somewhat more optimistic, but it's not necessarily a silver bullet. The new version may have been refactored, which is good thing in the long run, but in the short run, files, classes, functions, etc. may have been completely renamed; in a worst-case scenario, even the database structure could be feng shui'd beyond recognition.

Please understand that this is by no means a knock against free and/or open source software. Commercial code has certainly been known to break existing systems. For example: When Microsoft released the first version of .NET, developers could no longer count on being able to bring their old code forward and expect it to work. And when Microsoft released the next major version of .NET, they broke code written for the previous version. Which, needless to say, miffed more than a few folks.

The bottom line is: When you tweak "free" software to meet your specific needs, it's no longer free, and (more importantly) the tweaks in question may not be one-off costs. You could pay for them each time you need to upgrade. Some companies bite the proverbial bullet and have their mission-critical software written from scratch so that they control it. Others are more pro-active about managing upgrades (something that applies to proprietary software as well free or open source). Both approaches have their merits and there is no one-size-fits-all. However, downloading something, having it customized, and expecting to forget about it is just delusional.

Writing vs. translating

As I'm tidying up in the wake of my takeover of the world, one minor requirement will be that Universities, colleges and trade schools will be required to replace the phrase "writing code" with "translating code."

You see, even at their simplest, computer programs are acts of translation. Even taking out the physical acts of typing, mouse-clicking, etc.. functionality does not spring into existence ex nihilo. Why? Because someone, somewhere had to have first decided that making a computer do X was worth the time s/he thought that it would take. Thus the act of hewing X from the raw materials of platform and tools and code is the act of translating from human wants (and sometimes also the unspoken language of human needs) to the arrays of "on"s and "offs" that computer hardware understands.

Now go one step further and envision having to alter a program written by someone you never met to meet the needs/wants of someone you only sort of know. Three levels of translations are now required:

1. Translating the existing code into chunks you both recognize and understand
2. Translating the new/changed requirements within the context (and constraints) of that mental "codemap."
3. Translating the changes to the "codemap" into the programming language of choice.

My Latin prof. (in the late 1980s) claimed that "many" Latin students became computer programmers. I've never bothered to corroborate that, but on a gut-level it makes sense. Learning another language forces you to break the "natural" associations of phrasing and thought. (I can't recommend it enough, even if my love-hate relationship with Latin rivals that of my love-hate relationship with chess.) In short, you learn to respect your Mother tongue--including her limitations--and most especially the amount of linguistic "duct tape" required before two languages can express the same thought with the same nuances...when that's even completely possible.

And that, in essence, is what it's all about. For computer programming, anyway. The Hokey-Pokey, not so much. Because even the benevolent dictator of the entire planet knows better than to mess with the Hokey-Pokey.

Frivolous Friday, 12.11.2009: A silly-but-serious shout-out

As much I've been feeling a bit crispy around the edges, this post really goes out to the folks at work who are there when I stroll in, and are still slogging away after I schlep out. They vanquished today's deadline with the aplomb and tenacity that has become a commonplace miracle at the office. They are my lunch-box heroes. Again.

Signs You're Overdue for a Vacation

1. You dial "9" to get an outside line...on your cellphone.
2. You have to set a really freaky ringtone on your cellphone to remind yourself not to answer it with your "work" greeting.
   
3. Coffee that's been sitting on the burner for an hour doesn't taste so bad at four in the afternoon.
4. You and the cleaning staff know the names of each other's spouse/boyfriend/girlfriend/kids/pets/etc.
5. The Tivo overfloweth.
6. The four major food groups are: Pizza, Subs, Chinese take-out, and Caffeine. And not necessarily in that order.
7. You find yourself looking forward to coming in on weekends, because they're so much more quiet than Monday - Friday.
8. You start to log the time you spent working out a particularly nasty problem, then realize you did that in your sleep.
9. The dog barks its "stranger danger" warning when you come home, but the cat's actually started to miss you.
10. You see an ad for an interesting movie, and you instinctively guesstimate when you'll be able to catch it on DVD.
11. When you do meet your friends, you have to remind yourself that they don't look like their Facebook/Twitter/MySpace/WoW avatars.
12. You've racked up enough frequent flyer miles to qualify for a free trip to Mars.
13. Your expense account & reimbursibles add up to more than your paycheck.
14. The mini-fridge under your desk contains more food than the full-sized one at home.
15. Showering fully clothed with laundry detergent in place of soap doesn't sound like such a crazy idea anymore.

Still waiting for excellence in virtual office design

Despite the fact that it the office was quite cold today, it was good to be back. Not just because I've become spoiled by dual monitors. As much as I need to block out the doings of my co-workers most of the time, not having them close to hand adds considerable friction. (For the life of me, I cannot understand why we don't use IM. It cuts down on the over-the-cubicle-wall chatter, not to mention tells you at a glance who's in and who's out.) Oh, and keyboard latency sucks. A lot.

It occurs to me that what's missing from office design is remote office interface. This isn't merely self-interest talking. Green building (e.g. LEED standards) already involves support for remote workers. But, even working for a firm that's All About excellence in architecture & design, I have yet to hear about the contributions of the I/T & telecomm staff in any of their projects. It's still all about the space, which is frustrating. Because, ideally, a workspace should feel like an extension of one's mind, regardless of where one is located.

An unexpected lesson from junior high school

The textbook for my 8th Grade Spanish class included a short story about a child who is brought along with his mother when she visits a friend's house. The friend has a jar of candy, which, naturally, claims a piece of the child's attention. The friend gives the child permission to help himself to a handful of candy, but the child demurs, despite repeated offers. Finally, the friend dips her hand into the candy jar and gives the child a handful of candy, praising him for his politeness and restraint. "No Ma'am," thinks the child, "Rather, your hand is larger than mine."

That memory surfaced today as I took shameless advantage of the perk of remote access to my work desktop. Our neighbors have two sons, and they have both pretty well versed in the art of clearing a driveway of snow. The eldest does the rough, heavy work of chunking snow off to the side, and the youngest has the more painstaking job of exposing the asphalt. Not a bad system, all in all.

They were finishing up their own driveway when I hailed the oldest and weirded him out a bit by asking whether he and his brother wanted to make a few bucks by clearing ours by the time my husband (not similarly blessed with remote access) rolled back home from work. But when I asked what fee would be worth their time and trouble, I was met with a shrug. So--not knowing the going rate for driveway shoveling any more than I'd know the going rate for babysitting--I ended up naming the price. I strongly suspect that I dished out a double-handful of candy in the process.

Oh, well. I can easily rationalize it in the name of stimulating the local economy. And--to their credit--the guyzos did a far more thorough job than I would have done myself--even if I weren't buried in regular and extracurricular work just now. So really I was just outsourcing...yeah, that's it... [insert self-deprecating eyeroll]

Yet it drilled home (for me) the lesson that the grease on the wheels of capitalism is not, in fact, money. It's information.

"Information economy," revisited

I had some freaky results when trying to log into someone else's FTP server today, but, thankfully, I didn't have to sort it out myself. (You know who you are: Thanks again!) The issue turned out to be related to the site's setup and the hosting company's firewall more so than the FTP server itself.

But at the time I didn't know that. So I did what I normally do in such situations, which is to ping the Office Alpha Admin. Unusually (for him), he had no idea what the symptoms meant. So when I did have the answer in hand, I fired off the explanation to him, in case it was useful enough to squirrel away in his big administrator's bag of tricks. A small recompense for all the times that he has come through for me.

To me, the term "information economy" has a different meaning from the phrase hyped half to death during the decade previous. Regardless of whether or not we work in I/T, it functions all around us, just on the level of village (rather than global) marketplace. As it has done for millennia. I've worked in "villages" large enough to allow the most skilled to cheat layoffs by functioning, more or less, as a stockbroker (or maybe black market trader) in information. But in villages of all sizes, the trade is definitely based on barter rather than cash.

Which is maybe why I normally have so little patience for rumor-mongerers (on one end of the spectrum) and the self-appointed gatekeepers (on the other end). One floods the market with pinchbeck goods; the other hoards valuable information and artificially drives up costs to serve its own ends. Neither adds value, only friction. Because that's one market you want function as efficiently as possible for all who choose to deal.

Not a bad litmus test

I don't think that I've managed to rev up my metabolism enough to be ready for winter yet. Like many years previous, I'll fall back on the old standby of Upper Midwestern Stubbornness. Which means that, as my fingers stiffen and the engine temp has not moved the needle above ground level and I wonder whether I could score an after-market heated steering wheel, the race-memory of ancestors raised in Iowa and Minnesota blizzards kicks in. "Just what you need in a car: One more thing to break!" it scolds.

Sigh. They're a tough crowd, those ancestors. Doubtless I already scandalize them every day I live, even without such effete thoughts.

Being the geek I am, though, I almost immediately thereafter thought: "Hey, that's not a bad standard for software features, either." I certainly don't mean that no improvements should be made--we'd be driving the software equivalent of the Model T otherwise.

But acknowleging that every feature will probably need to be fixed or at least fine-tuned (or, in the worst-case scenario, overhauled) is a good tonic for the enthusiasm and kitchen-sink mentality that tends to permeate the design phase of computer programs, from 1.0 to what-version-are-we-up-to-now? Merely visualizing having to fix your pet feature--even without a (justifiably) cranky customer involved--has a tendency to bring things back to reality. Or, if you're squeamish about quashing the romance, consider it merely laying a solid foundation under your mansion of clouds. Whatever keeps one foot in Kansas and one on the rainbow...

Choosing to be a name or a number

1.) I really should do the responsible thing and send in the warranty card. It's a company I've done business with before, and one that--significantly--has not spammed me since, either in the email or snail-mail sense. But overriding the "training" other companies have given me over the years (via unwanted catalogs, "special offers", newsletters, etc.) takes more conscious thought that it should. Sad, that.

2.) Yes, it sounds whiny and "entitled," but I can't help but notice that Tumblr still requires its existing bloggers to click through to another login page (compared with Blogger, which does not), because its landing page is All About signing up new users.

I wouldn't even argue that all customers are created equal (because of the variance of needs/wants vs. the ability to meet them), much less that a first-time customer and repeat customer should be treated identically. Rarely can you determine how service varies from customer to customer. But when a company can't (or chooses not to) distinguish between new and repeat customers, it says a fair amount about the business model (in the case of established firms) or the greenness of its judgment (in the case of newer ones).

Granted, it's usually cheaper in the short run to be a number, and there are probably plenty of times that it's appropriate. Being a name requires interaction on your part, after all. But it is always a choice.

A moment of "Hmm"

Just something that popped into my head: How much is downtown revitalization hampered by the fact that storefront parking is typically parallel and and in traffic besides, as opposed to parking that's simplified by the gridded asphalt outside a mall or superstore? I'm not the greatest parallel parker, not by any stretch; fortunately, my small car makes up for my skill deficiencies. I just wonder whether that consideration subconciously affects many people's decisions when cars are the primary means of connecting Point A and Point B.

Frivolous Friday, 12.04.2009: Reimaginings

Just home from spending the evening working on a project with a fellow geek, which wound down with lively discussion of the various incarnations of the Star Trek franchise. Not surprisingly, at some point the deviations from the original series' "canon" came up. I know some folks who are purists that way, but a fictional universe that's over 40 years old can be expected to show a few inconsistencies.

Granted, there can sometimes be a fine line between re-imagining and re-hashing. Okay, maybe not so fine after all. Yet, when a fiction enters not just the zeitgeist, but the cultural psyche besides, re-imagining for each generation is just the price of doing business. Mae West quipped that it's better to be looked over than overlooked, and to be looked over over and over is not something to sneer at if you're a writer.

And, seriously, it's not just hack writers and directors who do this. George Lucas freely admits to pilfering elements of Star Wars from Kurosawa's Hidden Fortress. And speaking of Kurosawa, he had no qualms whatsoever about transporting Shakespeare's King Lear to feudal Japan in Ran. Just as Shakespeare himself had no problem lifting Lear's basic storyline of from the [cough] "research challenged" History of the Kings of Britain penned by Geoffrey of Monmouth in the 12th century.

But such refittings and re-trimmings pale when compared to the richness that is the tale of King Arthur. From the Romano-Celtic warlord of the late 5th or early 6th centuries through the Age of Chivalry (and Courtly Love) through Pre-Raphaelite wistfulness through the anti-war protest of The Once and Future King even down to the absurdist slapstick of Monty Python and (unfortunately) the kludgey kitchiness of Hollywood thereafter. But for a story that's stayed relevant to our cultural self-image for some fifteen hundred years, even travesties like First Knight are an homage of sorts.

So although I grew up watching reruns of the original Star Trek (not so long after the five year mission was scrapped two seasons in), I find it hard to get my pointy ears bent out of shape over "canon." If the retelling is confident enough to know when to color inside the lines and when to venture outside them to draw new meaning from time-honored memes, well, that's just another day in the life of literature.

A tragic anniversary

I'd prefer to write something upbeat tonight, particularly while feeling safe & cozy at home after the season's first snowfall. But my thoughts kept straying back to the 25th anniversary of the Bhopal disaster after running across the reminder earlier today.

The precise figures for the death toll that resulted when a Union Carbide pesticide manufacturing plant leaked enough chemicals at once to expose half a million people is still up for grabs. The most conservative body-count is on par with the 9/11 death toll, and may well be much higher. And the abandoned plant continues to poison the landscape and the groundwater to this day.

Not a single representative of Union Carbide--an American corporation--has had to stand trial for the ongoing pattern of negligence that resulted in what amounts to mass murder--not to mention the legacy of its malfeasance. In the end, it all came down to a financial settlement, a settlement as botched as anything you can imagine when an arrogant multi-national corporation and a corrupt government haggle.

But, as Pogo famously observed, "We have met the enemy and he is us." After a bit of diverging and merging, Dow Chemicals ended up with all but the Indian subsidiary of Union Carbide, and denied all responsibility for outstanding liabilities. Significantly, The Yes Men activist-pranksters highlighted how well stock market capitalism rewards corporate responsibility:

On December 3, 2004, the twentieth anniversary of the disaster, a man claiming to be a Dow representative named Jude Finisterra was interviewed on the BBC. He claimed that the company had agreed to clean up the site and compensate those harmed in the incident. Immediately afterward, Dow's share price fell 4.2% in 23 minutes, for a loss of $2 billion in market value.

Now, I'm all for making a fair profit--don't get me wrong. But murdering thousands and walking away from a health and environmental nightmare from which whole generations will not wake is not capitalism. It's colonialism. The East India Company might as well come back to hoist the Union Jack in India and trash its economy (again) for old times' sake.

Considering that we live in a country that will gleefully invade two sovereign nations to avenge fewer than 4,000 deaths, explain to me how we can consider the Bhopals of this world merely the cost of doing business. And, moreover, how we can possibly wonder why the 9/11s happen.

Are your thoughts being controlled by rocks?

This is not crazed paranoia talking. Really. My Latin prof. in college pointed out that the root for the words "calculate" and "calculus" was the Latin word for "rock," presumably because piles of stones were used as markers in accounting. (Not, I suppose, at all unlike the beads on an abacus or Incan "talking knots.")

Understand that I have a huge respect for the power of numbers in giving our human undertakings a precision that makes our whiz-bang-gee-whiz-gizmo age possible. That being said, from time to time I find myself scratching my head over how numbers--meaning counts--meaning, ultimately, piles of counting-rocks--can drive human behavior.

Two cases-in-point from tonight:

1. Me at the gym, on the elliptical machine with the wonky heart rate monitor which varied between 64 and 170. But I couldn't stop checking it anyway.
2. My husband snagging a pack of Thin Mints Girl Scout Cookies, and backtracking up the stairs as if to return them to their box after I called, "Forty calories apiece, by the way." As if the number somehow made them even more nutritionally toxic.
   

But what's even more mind-boggling to me is the tenacity with which people choose to latch upon a number--never mind how many corrections to the metrics come along to adjust reality. Songs are now 99 cents. So are iPhone apps. The bank bailout would set us back $700 billion. Recall that invading Iraq would be a $60 billion--chump change by comparison. Or maybe you're old enough to remember when gas cracked a buck a gallon: Remember the national freakout? If not, how about the freakout at the $2/gallon price-point? That's the stuff I'm talking about. Numbers are sticky in a way that most things other than bumper-sticker slogans are not. Whether they're true or not (just like bumper-sticker slogans).

All of which really, really brasses me off, given that I've taken more than my share of Math classes. Numbers are incredibly powerful--some even give a peek into the stuff of which our world (and perhaps the Universe) is made. And to see them confected and corrupted by slimy marketers and political spin-meisters makes me want to steal the batteries from their calculators and stick them into their ears just to watch their eyes light up...and not in a good way. Grrrr.

The point is, never underestimate the power of a number once it goes viral. Then it's pretty tough to crack or wear down. Rather like a rock, wouldn't you say?

The evolution of tools

Tools that can't evolve in tandem with your process(es) and your team will eventually hold you back. Home-grown tools are a blessing in that they typically are capable of keeping up with the people who use them. They're a curse in that you can't just buy yourself an instantaneous upgrade.

But handcuffing yourself to a vendor's tool-set (and its arbitrary schedule of upgrades) is much more risky, particularly if the vendor is a big corporation. Simply because this, in essence, amounts to paying someone to know what's best for people, processes, and (to a degree) your finished product. If you're a fly-by-the-seat-of-the-pants shop and the tools encourage a more organized approach, that could be a good thing: In that case, you're purchasing methodology along with bells and whistles.

But either way, never invest in any tool-set that can't adapt with you.