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.

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...

Frivolous Friday, 03.19.2010: Programmer bar jokes

Internet Explorer 6 walks into a bar and orders a drink. “I’m a little short on cash right now,” says IE6, “can I just start a tab?” “Nice try,” says the bartender.

A pre-1901 UNIX timestamp and a post-2038 UNIX timestamp walk into a bar and ask, “Has anybody seen our dates?”

A foo() walks into a bar()...

A gang of signed integers walks into a bar full of unsigned integers. After a minute, the bartender notices the subdued vibe in the place and wonders, “Whoa, where did all this negativity come from?”

An HTML FRAMESET walks into a bar and orders a beer. The bartender grabs a bottle of the most watery “lite” brew in the place, shakes it vigorously, pours the foam into a glass, and hands the glass to the FRAMESET, who disgustedly asks what the bartender means by that. “Duh, you’re a FRAMESET,” says the bartender. “You’re only supposed to have a HEAD and no BODY.”

A recursive function walks into a bar and asks to use the phone. “Local call?” asks the bartender. “Of course,” says the function...and dials its own cellphone number.

A group of sorting algorithms walks into a bar. The bartender hands them menus, and returns after they’ve pored over them for minutes on end. “Well?” he demands. The rest of the algorithms point at the bubble sort: “Sorry, he’s always slower at ordering than we are.”

A byte walks into a bar. “Are you ill?” asks the bartender. “No,” says the byte, “just feeling a bit off.”

Eight bytes walk into a bar. “Can I do anything for you?” asks the bartender. “Yeah,” reply the bytes. “Make us a double.”

Bill Gates, Steve Jobs and Linus Torvalds walk into a bar. “What is this?” demands the bartender, “A joke?”

Sign of the times

On my way home from tonight's Linux Users Group meeting, a pedestrian meandered across the road slightly less than a block in front of my car. "Old Towne"--meaning the vicinity of Caledonia Street--seems to hew to an old school ethic in its relative lack of lighting (gaslamp, anyone?). The resulting effect is shadows thrown every which way, some of which seem to move of their own volition. Fortunately (for both of us), the pedestrian was carrying a cellphone, the screen of which was fully lit, warning me of her presence many, many feet before her silhouette alone would have done.

Welcome to the era of the smartphone--not smart enough, alas, to prevent its owner from jay-walking (and at a leisurely pace). But smart enough to keep her from any real danger of being run over.

Shiny *and* a game-changer? I can hope...

It's been a while since I've been so thoroughly intrigued by sight-unseen software that I've had to fight a death-match with the urge to play hookey from my "To Do" list. My office-mate from a previous job pinged me (and others) today to ask for help testing the installation of a PHP/MySQL source control package and build tool he's created.

Both species of tools are good things--very few professional programmers would argue that. The deal-breaker, though, is that most of them have to be installed on (as opposed to just copied to) a server, preferably an off-site server (or one whose data is backed up offsite). Your typical Tucows/GoDaddy/Dreamhost-type web hosting company--quite understandably--does not respond well to Jane Customer asking them to install any old software on servers used by hundreds, if not thousands of customers.

However, the Zend PHP engine and MySQL databases typically come standard with any hosting package, which is what could make this concept a game-changer for the folks who don't do quite enough moonlighting to justify anything beyond McHosting. If it means source control with more discipline than Dropbox and fewer build steps than home-brew script files, that raises the bar for everyone--never a bad thing.

Again, I haven't done so much as download the software yet, but I'm quite excited by the concept. So, if you'll excuse me, I need to sneak in a little time for what I'm supposed to be doing, so I can play with the new toy and hopefully give my old "roomie" a little QA feedback in the process.

The earlier "no" is the kinder "no"

Seriously, if you think there's a chance you might not come through at all, just say "No" right up front. For the simple reason that a "no" merely closes off one possibility. But alternative possibilities can--an often do--have expiration dates. The longer you delay turning down whatever is being asked of you, the more likely it is that you're frittering away other opportunities for whoever is asking. You only have the right to close your own door, not others besides.

"Upgrading" information

The office bookshelf is located at the back of the "pod" I share with four other folks. Being the bibliophile, I'd say that this is as it should be, except it's really a graveyard for programming books that people (myself among the guilty) are too cheap to just throw away.

Normally, my Frugal Inner Midwesterner would consider a Kindle an extravagance ("What kind of book needs batteries?" it scoffs). But using an e-reader for technical books is one application that makes perfect sense to me. It's not just avoiding the waste of paper. The same obsolescence of technical information could provide a renewing revenue stream for publishers. You, the consumer, pay full price for your first edition of the book, then an incremental cost for updates when you upgrade the software in question and need upgraded information. I can even imagine a scenario that gives you a choice between having multiple versions available (should you deem it worth the disk space) and a seamless upgrade to 100% new content.

In other words, the process of publishing software documentation takes a few steps in the direction of publishing the software itself. Which is ironic, given that (IIRC) the makers of the first serious PC business application (VisiCalc) were paid along the lines of a book-publishing model, mainly because no one knew any better at the time. That didn't work out so well, but that's not to say that bringing the two models closer in this case would necessarily be a bad idea.

Unfortunately, I very much doubt that book publishers (with notable exceptions like O'Reilly Press) would view it in that light. Which is sad, because this solution, to my mind, is pure upside. Most especially for the trees.

Worse than broken

Well, that's frustrating: No error message in the web server log files to tell me why my sample PDF is nearly blank when it's generated by the test website I set up. (Fortunately, it works just fine on the live system--small mercies an' all...) But, in writing software, there is, in fact, a state that's actually worse than just plain "broken." And that's "broken with nothing to tell you why." One of my former co-workers claimed that the absolute worst is when software works (when it shouldn't) and you have absolutely no idea why. He has a valid point. But tonight, this is plenty of "worse" to deal with, thank you very much.

Cherry-picking technology

I'm playing catch-up on reading postponed by last week's "indisposition," and two particular articles from @artechnica kind of knocked together: "How Nokia helped Iran "persecute and arrest dissidents" and "China and Google playing game of Chicken over censorship."

Then I realized that it wasn't just outrage over companies like Nokia and Google going over to The Dark Side. It's also the ridiculous notions that companies are humoring tyrannical governments (or even theoretically democratic ones like New Zealand) in their delusion that they can cherry-pick technology at will. Frankly, it's as stupid as people who use the communiations smorgasbord of the internet as an echo chamber to circulate email and visit websites that reinforce their pet conspiracy theories or find (cough!) "evidence" to support quack notions.

And the bottom line is that there's no having technology both ways. The only real choice is between having technology at all or living in the Dark Ages. Not to go all Godwin, but the argument that following local laws absolved a corporation from charges of collaboration didn't hang in the last century. And if, in future decades, the dissidents (or their families) sue the shorts off the Nokias and Ciscos who dobbed them in to their soi-dissant "governments," I fervently hope that there is no mercy in the settlements. Live by the greenback, die by the greenback, you craven slimeballs.

But if the next global growth industry is technology that allows people to circumvent the snooping of their governments--no matter how democratic--so much the better.

Frivolous Friday, 03.12.2010: A new web comic

A librarian friend pointed me to "Not Invented Here," which is relatively new (as of September of last year), and I've been following it for the past few weeks. If you're in software development, this should definitely hit home at some point. Granted, Dilbert's done that (sometimes painfully), but Scott Adams hedges his bets by merging traditional engineering and software job elements. (Cheater!)

So jump back to the beginning and enjoy. Because, after all, any web comic that contains the sentence "It looks like a Rube Goldberg machine as drawn by Escher on LSD" can't be all bad--am I right?

Shut up and be awesome

One of my co-workers is being sucked into my project more than planned, because he's far more familiar with the temperamental nature of a key piece of the software infrastructure. And he's had a slog of it, not made any easier by the fact that he has to wait anywhere from several minutes to an hour to discover that the latest round of typed incantations has not appeased the software in question.

He showed me the results of a significant breakthrough he'd made today. "You're awesome," I said in appreciation of his doggedness. Alas, he's not the kind of guy who takes praise well, and immediately started to verbally sidle away from it. "Oh, just shut up and be awesome!" I said, half-laughing with exasperation at this quirk of his.

Come to think of it, it's not a bad antidote to the SXSWi hype this week, with all the launch parties of near-identical apps (fueled by booth babes and free booze). Maybe it's just me, but I'm starting to feel that fin de siecle malaise born of the sense of too many hipster software companies mistaking the zeitgeist (read, narcissism with GPS) for The Next Big Thing. Which, if my gut is correct, means that deep down the hipsters know it too, and much of the noise is them talking themselves out of that.

Or maybe I'm just older and crankier than usual today. That being said, I'd still appreciate some shut-up-and-be-awesome from the zeitgeist. kthxbi.

Software tester recruiting: Weer doin it rong

I'm quoting from memory here, so kindly forgive any inaccuracies: Dogbert receives a letter informing him that he has jury duty, and complains bitterly that he hasn't time for it. Dilbert reminds him that it's his civic duty, which is does nothing to mollify him. "You get to play God with other people's lives." points out Dilbert. "Well, they should say that!" snaps Dogbert, scowling at the letter.

La Crosse isn't large enough that the schools can viably offer programs/certificates in software quality assurance, so screening testers is a bit more challenging. And, sadly, it doesn't seem to be the kind of vocation that kindergarteners aspire to have when they grow up. Rather like taxidermy. And beekeeping. (NQSFW--one effenheimer involved)

But maybe all the trade needs to bring more of the brighter lights to it is the cachet of destroying things--but in a disciplined way. Maybe something on the order of the controlled demolition teams. Or the old adage "Military engineers build bombs; civil engineers build targets." That sort of thing.

The attitude does matter, I think. Case in point: For my very first programming job, I came on board very shortly after the rollout of a new order processing system (a.k.a. "The GUI"), which was a fiasco from the get-go. I wasn't allowed to touch the code, b/c it had been outsourced, and we were making the vendor deal with it. The testing pattern involved me making a preliminary check before installing "The GUI" on the PC of one of the customer service reps, one who was none too amused by its endless deficiencies. But once she saw it as a challenge to "break the GUI," and started taking a certain--completely understandable--joy in it, we made a fair amount of progress. Initially, "the GUI" colored her opinion of me, but once I started addressing her as "Lady M--- GUI-breaker" or "Lady M---, She Before Whom All GUIs Tremble," (with the appropriate courtly bow) we got along quite well--to the point where right before I left on my last day, she called me to gleefully sing, "I broke the GU-I!!!" like a little kid.

And so I think that the Software QA trade needs to emphasize the blowing up aspect of things. Contrary to the notion of what QA people are supposed to be like (meaning, methodical as accountants), you don't necessarily want purely linear thinkers. Why? Because users aren't necessarily linear thinkers. I know that users have occassionally done things with my code that has buried the needle on my "Illogical" meter. For that reason, I think that you need a chaotic subtext to the personality. So why not market the job to the Crazy Harry that lurks inside the mild-mannered software tester?

- - - - -

So. About that hiatus... The cough and congestion I whined about last Thursday blew up into something far more deblilitating. I did make it into work yesterday, but it took pretty much everything for the day. As if I need another reminder that I don't appreciate health and the absence of pain nearly enough.

Can you solve a problem in shifts?

The Alpha-Geek is on vacation this week, so it was left to three different peeps to bring their skill-sets to the problem-solving potluck today. My skill-set, mind you, was the least of them, but it was "my" project so, in actuality, I was just the cat-herder. (If you have cats, you know that's not necessarily a pejorative.) The point is, that the problem wasn't solved until all three folks were in the same cubicle at the same time. Even more to the point: All parties in question were crystal-clear on what the final product is supposed to look like--and gathered around the computer that showed that the final product didn't much resemble it.

I'm not knocking outsourcing; it certainly has its place. But the "globalized workforce" notion of round-the-clock teams handing work off between shifts like it's a baton in a relay is--in my less-than-humble opinion--twenty-four-caret hogwash. Bottom line: You're just not going to get a hive-mind level of collaboration in that scenario. If you want an illustration, try this exercise:

1. Think of some little feature you wish that your computer, smart phone or favorite gadget could have but doesn't.
2. Write down what it should do. In excruciating detail so that even the proverbial dullest knife in the drawer can't possibly misunderstand you.
   
3. Add mockups of screenshots.
   
4. Flow-chart of every possible combination of clicking, dragging, minimizing, maximizing, scrolling, etc. to make sure that you don't have unintended consequences like data loss.
   
5. Have that documentation translated into at least two different languages.
6. Make sure that your contractors understand exactly what it is you're shooting for in all that documentation.
7. Give the contractors money, sit back and wait for the final product.

If you vet your contractor well, you'll get back exactly what you asked for at the time you handed off the project. (If you phone in mid-project additions/changes, no pity for you!)

Alternatively, you could specify less detail up front, at the cost of making time for any number of review meetings--particularly early in the project--and a certain amount of "slop" in the schedule and budget as things are re-worked and reviewed yet again. Your call.

In all honesty, I won't deny that it just might work for a discrete, highly targeted set of features. Good on you if it does. Seriously. But seeing how much of a communication gap there can be between bright people who have worked together for years, natively speaking the same language...call me skeptical for the larger projects. Even accounting for a certain protectionist bias on my part. Maybe I'm not giving collaboration tools sufficient credit, but I just can't see any substitute for having all the right peeps in the same place at the same time when it counts.

Meme hangover

It's almost synchronicity, the way the "friction" meme from last night's Test-Driven Development presentation seemed to carry over into today. In the proverbial nutshell, the basic idea is that the less fiddling (i.e. friction) is involved in toggling between writing code and testing it, the more likely it is that things will be tested early-on. As anyone outside as well as inside the trade can imagine, that's a very good thing--the earlier a bug is found the cheaper it is to fix.

Today I had to dig out a bit of legacy DLL code written in Visual Basic 6. I actually didn't mind the language itself, but boy-oh-boy, do I ever have a problem with its compiler--specifically its little quirk of not unlocking the compiled code file after it's done. To date, my co-workers and I have found but one solution: Reboot. There's no euphemizing: That sucks swamp-water. Specifically, a swamp sandwiched between a swine-farm and a Superfund site.

But in this case, there's a workaround of sorts. Visual Basic 6 has a web language counterpart, VBScript. Think of them as two half-siblings who take after their common parent in looks but aren't as similar as they might be. But the resemblance is close enough that I can copy the new VB6 function into a web page, make a few tactical replacements, cheese out some wrapper HTML code to validate output, and testing is only an F5 key-press away (with maybe a right-click-and-pick-"View Source" tagging behind every few reloads) . When I'm pretty confident that the code's doing what I want it to, it's just a matter of reversing the replacements, and pasting it back into the DLL source.

But the point is that it's ridiculous that I have to do that at all. Mercifully, it's not like VB6 and I are the BFFs we were eight years ago. (Okay, so maybe we weren't BFFs, even Back In The Day. But still...)

Shout-out

I just wanted to say a big "Thank you" to the @devCoulee masterminds for pulling off an excellent kick-off meeting--easily the most polished for any group that I've ever seen launched. But the atmosphere was also felt very relaxed to me, which is no trifling balancing act. Congratulations, guys! I look forward to seeing folks again later this month.

Matching solvers to problems

Just armchair psychology here, but I think that, in the context of a software problem, the fight-vs.-flight response differentiates the true hackers--I mean that in the good sense, by the bye--from those who write code for a living. As you can imagine, the hacker will latch onto a problem with the grip of a bull-dog's jaws and the tenacity of Death itself. (Which is both an upside and downside, as anyone who's had to pry any dog's jaws open will appreciate.)

But here's the rub: Not all problems are created equal. When the "problem" is rescuing people from their own sloppiness/laziness, pffffttt: fuggeddabouddit. Give it to the "flight" crowd and don't be silly enough to expect enthusiasm. When, on the other hand, the problem approaches the software equivalent of a double-dog-dare, that's a different matter entirely.

In other words, if you want progress, know your "solvers" and choose your "problems" well.