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.