Frivolous Friday, 03.26.2010: Elizabeth and Henry grow up

When we learned the "There's a Hole in my Bucket" song in 6th grade, the boy's name was Georgie, not Henry. (Chalk one up for unorthodox education.) Even at the time, I thought the song ridiculous and reverse-sexist (because Henry's a right dolt), and I haven't changed my mind in the intervening thirty years. But the meme and tune have been stuck in my head since noon today and show no sign of leaving. So, to ape Marshall Crenshaw, I've suffered for my art: Now it's your turn.

There's a flaw in our process, dear Liza, dear Liza,
There's a flaw in our process, dear Liza, a flaw!

So fix it, dear Henry, dear Henry, dear Henry, dear Henry,
So fix it, dear Henry, dear Henry, fix it,

But how shall I fix it, dear Liza, dear Liza,
But how shall I fix it, dear Liza, fix it?

Walk the floor, dear Henry, dear Henry, dear Henry,
Walk the floor, dear Henry, dear Henry, walk it.

But what should I look for, dear Liza, dear Liza,
But what should I look for, dear Liza, look for?

Small details, dear Henry, dear Henry, dear Henry,
Small details, dear Henry, dear Henry, details.

But how shall I note them, dear Liza, dear Liza,
But how shall I note them, dear Liza, note them?

With your smartphone, dear Henry, dear Henry, dear Henry,
With your smartphone, dear Henry, dear Henry, smartphone.

But how do I upload, dear Liza, dear Liza,
But how do I upload, dear Liza, upload?

By email, dear Henry, dear Henry, dear Henry,
By email, dear Henry, dear Henry, email.

My inbox will fill up, dear Liza, dear Liza,
My inbox will fill up, dear Liza, fill up!

Then filter, dear Henry, dear Henry, dear Henry,
Then filter, dear Henry, dear Henry, filter.

By what rules should I filter, dear Liza, dear Liza,
By what rules should I filter, dear Liza, filter?

Your objectives, dear Henry, dear Henry, dear Henry,
Your objectives, dear Henry, dear Henry, objectives.

But how do I set them, dear Liza, dear Liza,
But how do I set them, dear Liza, set them?

A task force, dear Henry, dear Henry, dear Henry,
A task force, dear Henry, dear Henry, task force!

But how can I guide them, dear Liza, dear Liza,
But how can I guide them, dear Liza, guide them?

A process, dear Henry, dear Henry, dear Henry,
A process, dear Henry, process.

But there's a flaw in our process, dear Liza, dear Liza,
There's a flaw in our process, dear Liza, a flaw!

. . .

Living fossils

As further proof that having ideas carries their own punishment, it's put-up-or-shut-up time for me at work. Which means extracurricular meetings and being expected to come up with more ideas. And, oddly enough, reading assignments. Among them is the classic Dale Carnegie "How to Win Friends and Influence People." Somewhere I had the notion that the book was a product of the Fifties--a notion quickly dispelled by the introduction. (Interviews with the Thomas Edison? That didn't involve a Ouija board? Wait--what?") Actually, it was first published in 1936 when America was in the throes of The Great Depression, but bore the central message that ultimately made him wealthy, even by the standards of that bleak time.

After skimming the introduction and contributed piece by Lowell Thomas, I settled in for a slice of time capsule. But the version of the book I had had been updated so many times that it was something more like a living fossil. For a History nerd like myself, the anachronistic hodge-podge is somewhat jarring (reading it in PDF format didn't help, mind you!). And I was not amused to discover that business self-help books have apparently been following the same formula for much longer than I'd imagined--the "formula" being:

1. Break the message down into simple, but interrelated semantic chunks.
2. "Prove" your arguments with cherry-picked anecdotes.
3. Give your anecdotes credibility by quoting famous people. Preferably dead ones.

All that being said, I'm still reading it. More, in fact, than the "assignment" requires. One, that's just how I roll. Two, I'm a sucker for stories. Three, the central tenet of "Get over yourself and pay attention to what's important to others" is a healthy counterbalance to me spouting my semi-informed opinions to the inter-tubes every day. And--though I shouldn't admit this--one of the anecdotes mentioned the town where I grew up (Eau Claire, WI), thus illustrating the book's sub-premise that you'll never lose by mining a prospect's background. Sigh: Sometimes self-awareness sucks. Like now.

Will work for stickers

Our QA person found a bug that's been in a web page for I-don't-want-to-know-how-long when she tested functionality that I'd just added. When I "atta-girl"ed her on the finding, I semi-teased, "A gold sticker by your name today!" A bit later I skimmed a Harvard Business Review article that touted three sure-fire uses of social media, one of which was giving readers/subscribers widgets or badges for their own websites or profiles. Then it occurred to me that even adults covet stickers by their names; only the medium has changed. That makes me smile.

When the sequel is better than the original

Normally, the idea of mega-companies telling governments what to do scares me far more than the reverse. Simply because politicians can be voted out of office, whereas the stock market handsomely rewards sociopathic behavior when it boosts the current quarter's numbers. This is not one of those times.

When the rumors leaked last week of Google shuttering its Chinese branch, I was pleased, naturally. But, to a certain extent, it had the feel of a tactical (maybe even strategic) retreat from a no-win situation. PR-wise, it was a win--after all, who's going to side with a government that will send tanks against demonstrators?

But it's another week, and Google taking on the ridiculous nanny-state censorship of Australia is something I consider a legitimate exercise in speaking truth to power, and applaud it accordingly. Because the most fundamental part of that "truth" is that when allegedly "democratic" governments impose sweeping restrictions on internet content, it leaves zero room for condemning real oppression. It's no different, really, from Western governments insisting on "back doors" be built into protocols to "intercept terrorist messages" or installing thousands of video cameras in the name of "reducing crime." Purity of intent has zero relevance, because the proverbial kitty's out of the burlap at that point: Snooping into the doings of the average citizen has been justified. And--let's be honest--even The Land of the Free and Home of the Brave has produced the likes of Joseph McCarthy, J. Edgar Hoover, and Richard Nixon's thugs. Can you just imagine what any one of them would have done with Carnivore at his fingertips? Pretty scary, hey?

Like Dennis says, if you want to wear the white hat, you'd better make sure it fits. And so I can only give major props to Google for calling out the democratically-elected Australian government for adopting the tactics of a totalitarian regime.

- - - - -

Speaking of transparency, something I should have thought to note with previous posts mentioning Google is the disclaimer that my husband & I jointly own stock in the company. And, if the market--as is its wont--punishes The Big G for doing the right thing, we may well snap up more.

False dichotomies are the most dangerous

Believe it or not, this isn't another slam on Adobe. Ars Technica saw fit to publish something that smells awfully like a press release today: Adobe to unify ColdFusion, Flex, Flash with FlashBuilder4. (My inglorious 13-month "career" as a journalist saw me cleaning up any number of these things--enough to flatter myself that I know one when I see it.)

Anyhoo, one sentence in particular darned near drove me up the half-wall of my cubicle:

Flash Builder 4 includes support for Adobe's still beta Flash Catalyst rapid UI design tool, which, along with Flex 4, will enable designers to work on the front-end independently of back-end development.

When will managers stop buying this snake oil?! Not the product itself, but the notion that you can put the Berlin Wall between designers and developers. Ever. In fact, I posit to my gentle reader that management not only robs its own pocket in paying for such "solutions," but does its end-product incalculable harm by believing that it can structure its process around this alleged "independence" of function.

Understand two things: Firstly, I barely need both hands to count number of graphic artist/designers with whom I've collaborated as a developer--i.e. the-plural-of-anecdote-is-not-data. Secondly, I'm painting with a double-wide brush in characterizing visual designers as right-brain and programmers as left-brain. That being said, fantasizing that UI people and backend people speak the same language (even when working side-by-side) is twenty-four-caret folly--as it is when you mix any pair of complimentary disciplines. Now, the skeptic could make the case, "Eh, so you're gonna lose some nuance. Big deal. That's what review meetings are for--to patch that up." Except that, even in the best-case scenario, a minimum of two review meetings are guaranteed for every "chunk"--however that's defined--of work to be done. How many meetings have you attended where everyone's come out on exactly the same page? Yeah. Me, I'm thinkin' that two is ridiculously optimistic.

The bottom line is that the front-end--meaning the part that users see--has to know what the back-end (the database and the server-side code) is expecting at all times. And vice-versa. Bad juju happens otherwise. Moreover, it greatly streamlines the communication between front-end and back-end when the front-end proofreads/validates data before pitching it over a network connection. Meaning that the UI requires "invisible" code that checks things as such as:

• Have all the required fields been filled out?
• Does this credit card number have the right number of digits?
• Does the expiration date of the credit card fall on or after today's date?
• Did someone try to enter a bogus date like February 29, 2010?
• Does the email address contain an "@" and a dot-something-or-other?
• Are the dollar amounts positive or negative?
• Does the new password have at least six characters and a combination of letters (upper- and lower-case) and numbers/symbols?
• Is a malicious user attempting a SQL injection hack that could be nipped in the proverbial bud?

And that's not even accounting for more esoteric logic specific to the application/organization itself. Generally speaking, you need a programmer's hands in the front-end code to enforce whatever "rules" are dictated by the nature of the data being collected/processed. For that reason (even more than the realities of human interaction), I think that companies peddling the notion of "independent" design and development sorely need to be laughed out of business. And programmers & designers who work for the idiots who buy into the false designer-developer dichotomy should brush up their resumes and find a sane organization to work for.

Implicit code needs explicit documentation

You'd think that I'd have learned from seeing perfectly valid code subverted time and again by folder/file/database permissions that weren't what I thought they should be. But that's not the only thing that can produce huge disparities between code that seems to be executing and the reality that comes out on the other side.

In today's case, that had to do with the fact that an order submitted into a system was listed as being paid by Visa, regardless of the payment method actually selected on the web page. What was actually going on under the proverbial hood was that the database table was expecting one of a fixed list of specific values (known as an ENUM data type) for one of its columns when the new record was inserted. But the code in question, as it turns out, wasn't specifying a value, and because the table was set up not to take a NULL value for that field, the database--logically, to my way of thinking--automatically picked the first value in the list and ran with that.

Luckily for me, I've already been bitten by auto-magical behavior from other databases, so I had the gut feeling that something similar was afoot. One peep at the database setup and another at the database documentation smoked out the "gremlin." But I wonder how much time a more novice programmer than I could have wasted on debugging--typically a clumsy process in PHP, more so this highly modularized PHP code-base. A little internal documentation would have gone a long way in that case. Even in my case, it would have solved the mystery that much sooner.

Ultimately, documentation is an investment: Spend a little time up front and maybe a little incremental time when code's updated, and the dividend comes every time someone has to make a pass through the code. Which, in my experience, happens more often than when than code's actually changed. Quite typically, the person reading the code just needs to understand what's happening upstream or downstream of what s/he's working on. That alone is enough to insist that any "implicit" code execution--i.e. those auto-magical side effects--be specifically documented. If you don't think that your programmers have time for that, than you'd better allow plenty of time for programmers to scratch their heads when unexpected data shows up in the database.

How to depress a geek

Remind her that are there aren't enough waking hours in the week (even without a full-time job) to learn everything cool--much less everything useful--in her trade. Sigh...