Silly Saturday, 2018.11.24, the Kenny Rogers edition

On a late Sunday evenin',
At a start-up out of runway,
I sat next to The Greybeard,
We were both too tired to weep.
So we took turns a-sighin'
As the errors rolled from Jenkins,
'Til ennui overtook him
And he began to speak.

He said, "Grrl, I've made a life
Out of savin' founders' bacon,
Smellin' trouble brewin'
'Fore the pinks slips start to fly.
By the green hue of your skin-tone,
I can see you called your options
If you'll walk me down the hall-way,
I'll give you some advice."

So we headed to the break-room
And he kicked my butt at foos-ball,
Then opened up the drink-'fridge
And slammed a Mountain Dew.
Then the place got almost quiet
Once we set our phones to "vibrate."
He said, "If you wanna make the rent, grrl,
This is what you got to do."

[Chorus]
"You got to know when to ship it,
Know when to slip it,
Know when to refactor,
When to let things stand.
You never work ev'ry weekend
If the CEO's not there, too.
There'll be time enough for workin'
When the Round A lands."

"Now, ev'ry Greybeard knows,
That the secret to the pay-off
Is knowin' that ideas mean jack
When your team can't see them through.
'Cause every app. is Facebook
And every app. is Friendster,
And the best that you can hope for
Is your VCs know it, too."

And when he'd finished speakin'
He ordered up an Uber,
Buffed his LinkedIn resume,
Tossed his work-badge in the trash.
And once at his next start-up,
The Greybeard hit the jackpot.
But in his parting words I'd found
Advice that I could cash.

[Repeat chorus three times]

The limits of affordances

Just because I'm mostly a back-end (read database and business logic) developer doesn't mean that I don't care about UI or UX.  Mom drilled the ethic of putting myself in another person's proverbial shoes into me pretty early-on.

For what I usually do, that plays out in well-organised data-sets, scads and scads of validation code, and fighting tooth-and-nail for the absolute rock-bottom minimum of data passing back and forth between client and server.  Mostly do-able...assuming you aren't double-teamed by Marketing and Legal.  (Pro Tip:  Know your bandwith/hosting costs cold, have your calculator handy, and put the onus squarely on those noseyparker byte-hoovering data-slobs to quantify the ROI.  Preferably in front of upper management.  Chances are, they can't and won't.  And they'll think twice before doing it again.  Alas, twice isn't always enough times.  Lather, rinse, repeat.)

While my world is largely ruled by, well, rules, front-end designers and developers wrestle with the container-of-fuzzy-spaghetti-from-the-back-of-the-fridge otherwise known as the modern human psyche.  More power to them.  I've wrestled heisenbugs a-plenty (losing more than a few rounds, mind you), and still would rather re-fight every single one of those battles than allow a random user to type a DateTime value as plain text.  Seriously. 

Thus I'm a starry-eyed fan of design folks like Don Norman, Mike Monteiro, Erica Hall, and Luke Wroblewski.  (Viktor Papanek's magnum opus has been on my wish-list for years, but it's been out of print for so long.  Some day...)  Also behavioural psychologists like Daniel Ariely and Daniel Kahneman.  Likewise Clay Shirky when it comes to pointing out the differences in how humans act individually vs. in groups (absolutely critical in this connected age).

The single most important take-away from all this reading is:  Thou shalt make it easy for thy user to do The Right Thing(TM).  (In an ideal world, thou shalt make it statistically impossible for thy user to do the wrong thing, but -- Mike Monteiro excepted -- nobody in this crowd is rocking anything like Charlton Heston's beard from The Ten Commandments, so...).

And yet, for all that reading--in most cases multiple readings because it's all crazy-good--I find its limits no farther away than the local co-op grocery store.

Several years ago, I had both the keep-you-on-your-toes challenge and the genuine pleasure (because they shouldn't be mutually-exclusive) of holding down the account for a household-name client.  The kind of client that was flush enough to send holiday gifts to their vendors.  As a matter of corporate policy, I donated gifts like the cheese-knives and cutting-board to the office kitchen.  (Being the Patron Sinner of the office's "liquid potlucks," what else would I do with that kind of thing, I ask you.)

The two shopping bags were another story.  Lovely things, those.  Two sets of handles, for shoulder or hand.  Constructed from the recycled (PET) plastic equivalent of Grade-A Wakandan vibranium, IMLTHO.  (Or adamantium -- take your pick, Marvel fans.)  Crossed with a Tardis to boot.  They're awesome.  Especially when compared to the branded "resusable" bags hawked by the local grocery stores.  Two of which (in our household, at least) have been known to blow their seams in less than a month...one on the very next use.

So I, being a back-end developer aspiring to minimise my UI/UX sins, attempt to do the right thing by making it easy for my user (a.k.a. the cashier) to do the right thing.  Which means the double-decker short cart rather than the monolithic monstrosities with the turning-radius of a battleship.  Heavy stuff on the bottom (because Physics, nat'cherly) and little and/or smooshable stuff on top.

At the checkout line, the first thing dropped onto the conveyor-belt is the bags.  With the awesomer ones unmistakably on top of the not-so-awesome ones.  Then the groceries, carefully graded (front to back on the belt) from heaviest to lightest.  The affordance couldn't be plainer:  Put the stuff closest to you in these-here bags up-top.

Yet, well over 90% of the time (in my observations), the cashier dumps the awesome bags off to the side and loads the flour, the shortening, the canned goods, etc. into the el-cheapo bags and resorts to the industrial-strength bags only when the others have run out.

Why?  Because when it's the difference between the known and the unknown, afforances don't mean jack.  As far as the average customer and cashier are concerned, all branded "reusable" (in my case, the quotation-marks are there for good reason) bags are churned out by the same no-name offshore factory.  (And, for all I know, they are.  Booyah, race-to-the-bottom globalism, yo.)  The default option -- i.e. the ultimate affordance -- is the known quantity.  It's the same reason that the "Save" button still looks like a 3.5" floppy disk and not a USB flash drive or an SD card.  The exact same reason.

Which, while it's frustrating as all get-out, is deeply humbling.  It's why I consider darned near every UI/UX developer on the planet grossly underpaid.  As much as non-programmers puzzle (perhaps shudder) at the inner workings of computers, I embrace them as fundamentally logical -- ultimately knowable.  In contrast, stepping into the world of human-computer interaction means trading the near-certainties of Boolean logic for the fuzzier approximations of statistical norms...clouded by the occasional chaos of lizard-brained mob-thought.  [shudder]

Alas, my patron-client must have custom-ordered the awesome bags, because they have no manufacturer's tag.  (They're a dark olive green, slightly beveled bottoms, two sets of handles -- can ya do a girl a solid here, Intertubes???  Halp.) Or I'd cheerfully solve my weekly problem by ordering a few more.  ("Thou shalt make it impossible for thy user to do the wrong thing," remember???)

The other, cheaper, solution, of course, would be to just tell the cashier to use the weirdo bags.  Except that cashiers are basically just trying to optimise for ringing up as many sales as possible without getting yelled at.  At the risk of sounding ancient, I'm old enough to remember when ringing up sales (and making small-talk about the weather) was all cashiers had to do.  Another person not only bagged your groceries, but also loaded them into numbered tubs so that a third person could help load them into your car (if you so chose).  Contrast that with the utter faceless dickishness of Home Depot, et. al., and their self-checkouts, and you'll understand why I refuse to participate in any further dehumanisation.

Ultimately, computer programming, like any discipline, has to push the boundaries to stay relevant.  In the 1990s, we had the waggish adage of "Intel giveth and Microsoft taketh away."  And while I sometimes wonder whether an on-demand "serverless" world of ginormous anything-goes NoSQL databases and spaghetti-nets of asynchronous-microservices-du-jour will trash back-end coding as a legit. discipline, I have no such worries about UI/UX developers.  Those boundaries, however mystifying to a left-brainer like myself, are vast, but relatively immutable.  But certainly no less challenging for all that. 

"Experience is what you get when you were expecting something else."

That was the little bio. tag-line for someone on the Arduino forums.  (I didn't make a note of their handle.  Apologies!)  Granted, if you're trolling through the Arduino forums, you're already feeling that.  But boy howdy, that hit a little too close to home for me.

Backstory:  The chicken coop is almost finished from a structural standpoint.  For monitoring temperature, humidity, and ammonia (NH3) levels, I decided to take the cue from my neighbour and roll with a wifi-based interface vs. Bluetooth/Android. 

The wifi breakout board that I'm holding up below is the ESP8266:  Version 1.0 form-factor with the Version 12 firmware.  Go figure.

I've known for well over a year what a difficult little beastie it is.  

• The above form-factor's pinout is downright breadboard-hostile. (Two rows of pins?  Just...whyyyyyyyyyy????) 
• It runs on 3.3 volts (vs. 5 volts for most other things).
• Like all electronics that transmit a signal, it's a PIG for current (~300mA peak).
• Constructing and sending an HTTP GET request is super-fussy about syntax (including carriage returns) and timing.  At the time of writing, HTTP POST is above my pay-grade.

And as the proverbial cherry on top of all that lamesauce, my (Ubuntu 12.04) workstation has this nasty, sneaky tendency to quietly drop USB -> Serial connections.  When you're in the middle of debugging and already inclined to blame your code, this can waste scads of time.

But this, in addition to being my first full Internet of Things project (well, first non-proof-of-concept project, anyway) was only my second rodeo with a smaller microprocessor.  I've already gone a few rounds with the Atmega328 chip running on a breadboard.  It's the same chip used in the Arduino UNOs, which streamlines development (as much as development can be streamlined).

The squee little ATtiny85 is the baby of the Arduino family.  Its surface-mount form-factor is the brains of Adafruit's Trinket, so I'm already familiar with some of its...errrrr..."quirks."  (So, yeah, the "baby" can sometimes swing to more of the "Stewie Griffin" than the "Maggie Simpson" end of the spectrum.)

The biggest quirk is that peeking inside the head of the ATtiny chips is almost impossible.  (I've done it with another full Arduino and an FTDI/UART programmer, but the wiring alone would make Rube Goldberg shake his head.)  All the usual protocols you'd use with a full-size Arduino chip (I2C, SPI, full Serial) are not supported.  The best that the ATtinys can manage is the SoftwareSerial library.  Which looks all fancy-schmancy on the surface, but under the hood does something known as "bit-banging."

Now, without wading into the intricacies of two- and three-wire communication, let's just compare bit-banging to an intersection where the drivers only sorta-kinda follow the protocol of taking turns and where the cars don't always arrive at neat intervals.

The bigger Atmega328 chips require you to supply an external "clock" (a crystal oscillator plus a couple of capacitors) to time the exchange of ones and zeros.  And while you have that option with the ATtinys, you do it at the cost of two pins -- of which there are only five on the ATtiny85.  The remaining (and default) option is to rely on the chip's 8 MHz internal clock.

As it turns out, that clock doesn't exactly run with the tightest tolerances.  According to one reply on the Arduino forums, the slop can be as high as +/- 10%.

Yeeeee-OWCH.

The upshot was that the hit-to-miss ratio of the HTTP GET request even making it to the router intact was absolutely abysmal.  By contrast, when I ported the code to a full Arduino UNO, the ratio flipped.  Still not perfect, but more than acceptable.  When I wired up an Atmega328 on a breadboard and uploaded the self-same code to it, the results were the same as the UNO.  The relative reliability of the external clock made all the difference in the world.

Pity.  I had high hopes for that little cutie-pie of a chip.  I still plan on wiring up and coding a Bluetooth-based proof-of-concept with it.  Mainly to get a handle on its reliability..  As I mentioned, HTTP GET is hella-finicky.  The AT-commands used with Bluetooth are simpler, so there is some hope there.

In the meantime, I'm going into production with a slightly over-engineered "Mark I."  I still need to pick up a replacement NH3 sensor from BJW in Moncton (because guess who hosed up soldering headers and then nearly ripped off a couple of pads trying to de-solder them?), burn it in, and kick its tires.  And, finally, knock together a screened enclosure to proof the whole contraption against, ahem, "re-wiring" by a trio of curious -- and probably bored -- chickens.  (I've seen the movie Chicken Run, y'all, and I would not put it past any of them.  Related:  Remind me never to let them watch Iron Man either.)

For the longer-term, I have a couple more sketches for the "library" of Arduino code accumulating in a Mercurial repository.  For this project I imported the temperature and humidity code lock, stock and barrel and it worked right out of the box.  Which is the whole point of a well-organised code-library.  And with a tenacious sinus infection knocking me flat in the middle of this project, don't think that I don't appreciate my past self for that!

And, most important, this radically expanded my notes.  Most especially the "Gotcha" section of an Arduino-on-a-breadboard ("Boarduino") presentation that I might give sometime in the next few months.  Because while I consider this latest round of butt-kicking just another installment of paying my dues, I benefited hugely from the forums, etc.  And so I'm paying that forward.  Mind you, I don't worry about the next generation becoming soft and spoiled.  Because even if I spare someone this particular butt-kicking, there are plenty more lurking out there with each new project. Oh yes, yes there are...

Security SNAFU Solidarity

I could have applied by mail for my first Canadian passport.  But I figured that it worth the heavily-detoured trip into Shediac to have Service Canada double-check my work.  Turns out, my paranoia was rewarded by the fact that the agent caught two errors.

One was just a brain-burp on my part.  The other, though, is on Service New Brunswick.

See, to prevent counterfeiting, our drivers' licenses are watermarked (for lack of a better term) with both grey and silvery-irridescent text/patterns.  Then "personalised" information (number, name, DoB, etc., etc.) is printed over that.  In my case, the watermarking seemed to affect the printing of one number so that it looked very much like another.  Especially given that that the numbers are printed in red instead of black.

Fortunately (and unsurprisingly), I had to supplement the application with photocopies of photo-ID.  In black and white, the number in question is far more legible.  Which is how the Service Canada agent caught the mistake.  (Whew!)

Needless to say, as a member of the I/T tribe, I found this more than a little ironic.  I kept a straight face, but I couldn't help but think (sarcastically), "Hmmmm...securing information by making it less usable and its users more error-prone:  Where-oh-where have I seen this before?  Oh, riiiiiiiiight..."

Scarier thing is, my British-born neighbour told me that the UK passports now require biometric data--e.g. retina scans.  I can only begin to imagine how securing digital-based data with meat-based data is going to complicate things in unintended ways.  (True, glaucoma and diabetes don't seem to affect retinal biometric reading too adversely.  But still, I'm totally thinking about that scene from The Avengers.  Of course I am.  Blech.) 

Don't egg me on

Our current neighbourhood is a little more communal than the previous one.  Maybe it's an Acadian thing.  But the borrowing and sharing (especially when the gardens are coming in) has an old-time small-town feel. Thus, I was seriously-and-for-realz not at all surprised to see a text from the across-the-back-lawn neighbour asking (out of the blue) whether Dennis would want to borrow his spare chicken-coop in lieu of Dennis having to scramble one together before the snow flies.

Because that's just what good neighbours do, right?

Dennis will probably build to his own design anyway, but it's good to know that it's there in case the weather makes the tarp-covered Quanset-hut run inadequate for the three remaining birds.  Because of the need for a heated waterer, we'll need to run electricity out to the coop.  Which opens up other possibilities for monitoring things like temperature, humidity, and overall air quality, etc.

The app. I have in mind is Bluetooth-enabled, allowing an Android app. to check in on the current status of those numbers and setting off an alarm if the numbers get out of whack.  And there's less than no sense in keeping that design/code to myself if someone else can get the benefit of it for the cost of a few electronics components.  So I texted our neighbour to see whether they have any Android devices in the house.

Because that's just what good neighbours do, right?

(Well, not one hundred percent:  A second set of feathered guinea-pigs for field-testing benefits me, too.  Let's not get too crazy with the altruism angle here...) 

Nope, texts the neighbour:  They're strictly an Apple household.  (Fooey.)  But then he asks how they would keep the stored data.

Hoo boy:  That's a whole 'nuther basket of eggs.  Because now we're talking back-end:  Databases, a web application, all that jazz.  Granted, that's basically my core competency as a developer.  But it's also scope-creep (on radioactive steroids!) at this proof-of-concept juncture. 

And yet.  It's also useful to know that someone's already thinking long-term.  Assuming that I ever wanted to jump through all the UL-type certification hoops to sell this kind of contraption to backyard chicken-herders.  Mind you, two data-points do not define a market, but the fact that a single text dragged the scope so far outside the pale tells me that I wasn't thinking "holistically" enough.  Even for this six-chicken neighbourhood.

But, then, that's just what good neighbours do, right?

Death, be not ironic *

The news is a little stale, mainly because I've been lazy when I've not been shaving yaks.

Jean Sammet passed away a little over a month ago.  And while I bless the New York Times for dispelling a myth I've lived with for about two decades, I'm equally outraged that this was the first I'd heard of Ms. Sammet's work.  When I re-booted my computer programming education in 1996, the curriculum included the COBOL programming language.  (Gen-Y and older folks will remember the Y2K non-event, which was proceeded by a sharp demand for such, ahem, vintage languages as businesses threw money at decades of technical debt.)

COBOL was/is indelibly associated with Admiral Dr. Grace Hopper, who is largely responsible for the fact that "programming" no longer involves building software with tweezers, pushing ones and zeroes on and off stacks of memory-addresses.  (Assembly-language is the closest you can get these days.  I tried it once.  Once. [shudder])  One of my teachers -- himself a PhD -- was immensely proud of having met her...and the fact that she, by that time a senior citizen, was exhausting to keep pace with.

But, as it turns out, "Amazing Grace" didn't design so much as a feature of the language.  No question that her work was absolutely foundational to it (and, really, everything since).  But, as Ms. Sammet's obituary points out, Hopper's "Mother of COBOL" moniker is entirely undeserved.  (Hello, Halo Effect.)  The actual credit belongs to Ms. Sammet and five other programmers who slammed out the design in two weeks.  (In the days before Red Bull and foosball tables, if you can believe that!)

What I find interesting about this era in computing history is the sense of a battle for the soul of computer programming.  Dr. Hopper's work was, at it base, driven by an abiding love of mathematics.  She found the bit-twiddling a needless waste of a mathematician's time, and she bucked management to develop a more English-like grammar.  (Woo, skunkworks project!) 

In contrast, her fellow force-of-nature, Ms. Sammet, seemed more influenced by working for hardware manufacturers, absorbing the culture of calipers, slide-rules, etc.  And it comes through in her view of software as the product of a more rigorous engineering process.  (A view echoed during my stint at IBM in the early 2000s when "the process is the product.")

In the end, however, neither of these formidable ladies was entirely correct.  Because software was quickly co-opted by business, where neither mathematical precision nor engineering rigour can stand up to the short-term profit motive...and the long-term tendency to kick the can down the road.  Fittingly, the NYT obituary for Ms. Sammet concludes:

"COBOL was initially intended as a short-term solution to the problem of handling business data — a technology that might be useful for a year or two until something better came along. But it has lived on. More than 200 billion lines of COBOL code are now in use and an estimated 2 billion lines are added or changed each year, according to IBM Research."

Apart from the term "bug" that has been Adm. Hopper's ubiquitous contribution to the programming lexicon, you'll sometimes see her quoted along the lines of, "The most dangerous phrase in the English language is, 'we've always done it that way.'"  But there's also the (anonymous) adage, "If it ain't broke, don't fix it."  As programming languages go, "something better" has probably come along in the last fifty years.  Just not "better enough" to justify tossing out the engineering that went into the original COBOL-flavoured solutions.  And that in itself is one HECK of a memorial.

- - - - -

* In case it matters, title is a riff on one of John Donne's poems.

You can't copy-and-paste a career

[Warning:  Rant ahead.]

Because filing paperwork that will almost certainly be a waste of paper & printer ink & postage (not to mention the time of all involved) wasn't infuriating enough, this had to land like a fresh cow-pat across my path in Twitter today:  Computer science students should learn to cheat, not be punished for it.

The tl;dr summary was best done by Homer Simpson (quoting from memory here):  "Marge, don't discourage the boy!  Weaseling is an important skill.  It's what sets us apart from animals...except, of course, the weasels."

Because, you see, in The Real World(TM), coders copy and paste all the time.  And coding in school should reflect the less ethically pristine norms of Silicon Valley.  At least, according to a journalist who lists precisely no coding background in his profile.

Oh, and teaching Java as a first language is somehow corroding professional skills.  I say "somehow" because there was literally no explanation for that offered in the main article.  The CrossTalk URL stalls out.  (Pity--it looked much more promising.)  The second related URL links to another article by the same author which argues that JavaScript is better because it isn't as scary and thus doesn't discourage the "fundamentally creative endeavor" that coding is supposed to be.  (No, really, it said that.  I wish I were making that up.)

Because schools, you see, are failing the software industry, and the 10% unemployment rate among UK CS graduates is iron-clad proof that Universities aren't teaching real job skills.

I mean, no real job skills besides sitting in herds pretending to be interested in what the authority figure at the head of the room is saying.  Or to subsist on crap food consumed at irregular hours.  Or the mad, scrambling stampede ahead of arbitrary deadlines (a.k.a. the semester).  Or swallowing the seething rage that comes with individual performance ratings being dragged down by slackers you didn't want on your team in the first place.  Or, not least of all, the almost rhythmic filling and emptying of your memory with the Next New Hotness that we need you on the bleeding edge of so we have someone to tap when we're finally forced to use the industry standard five years hence.

And now a journalist is advocating stealing--notice I didn't say borrowing--code as a professional skill. 

Now.  I spent about a year in the Fourth Estate, and even after more than two decades, I can appreciate how your knowledge has to be the proverbial mile-wide-and-an-inch-deep.  I know that I had to lean on other people to understand the intricacies of red clay vs. blue clay in the street renovations, the problems caused by shoddy contracting on the new high school, and even which number under that pile of jerseys was actually holding the football.  But I leaned on people who actually knew what they were talking about.  Reporting on something from your personal "Hello, World!" perspective is a great view into how beginners view things.  But it does not qualify you to design curriculum for an entire industry.

But!  Surprise twist!  I actually agree in principle that four-year University degrees are doing no one any favours by devoting weeks' worth of time to edge cases like sorting algorithms.  Or discrete mathematics.  Or even much NP-completeness theory beyond the basic epiphany that not all software solutions can be encapsulated by an algorithm.  (Turning a brilliant-but-naive coder loose on something that they don't know can only be approximated or brute-forced will waste one heck of a lot of money.  Let's avoid that, but not go too crazy on knapsack problems, m'kay?)

And I certainly can't argue that coming out of school knowing unit-testing, source control (particularly the Special Hell(TM) of branch merges) aren't a bad thing.  Replace pop-quizzes with Scrum stand-up check-ins, for all I care. 

But school already does a bang-up job of reinforcing some of the worst aspects of the world of work.  (See above snark on "real job skills.")  Stealing code should not be added to those sins.

Borrowing code is an entirely different matter.  By "borrowing" I mean citing the source (e.g. the StackOverflow URL) in the comments.  That accomplishes a few things:

1. It allows you (or the poor slob who has to maintain your code) to go back to the source for reference.  Which can answer questions like:  "What was the original code meant to accomplish"?  "How old is it?"  "Was the solution up-voted and/or embellished with further useful comment?"
2. It demonstrates to your team-mates and/or bosses that you don't take credit for other people's work.
3. If the code completely bombs QA/CI tests, you don't look like quite the idiot you would have it had been your own creation, amirite?  ;~)

The first point is more immediately and practically useful.  The second, however, has more far-reaching implications.  We've seen billion-dollar lawsuits filed in the name of code-stealing.  (Remember SCO Linux?  No?  Okay.  Howsabout the "APIs are copyrightable" legal Wrestlemania between Oracle and Google?)  My industry is notorious for men claiming credit for women's contributions.  And someone thinks that taking credit for other people's work is a skill to reward from the age of 18 on?  Because citing your sources is for academia (and, one hopes, journalism)?  Seriously???

The good news is that there is a stupid-simple way to stop universities from turning out unqualified junior programmers.  Seriously.  Paint-chip-eating-stupid-simple.

Ready for it?

Programmer job postings just need to stop requiring CS degrees.

That's it.  Supply, meet demand.  Next problem, please!

Okay, so there's actually some bad news:  The Suits won't stand for that.

Let's take a minute to break that down.  If The Suits absolutely must hire an onshore programmer, that's not chump-change.  Granted, the modern (read: "internet-ified") job search process does a fantastic job of externalising much of that cost on the job-seeker.  But there is some residual internal cost to hiring.  That cost rises dramatically after a newly-acquired warm body is parked in its cubicle-stantion.  Mainly because most new hires require 60-90 days to evolve the dysfunctions necessary to survive in their unique new corporate micro-climate.  (But I'm not cynical.)  Two to three months of salary plus overhead is not an insignificant investment.  The bean-counters are right to want to minimise the risk that the new organism they've introduced will turn out to be a parasite.

Suits want security and stability.  Disruption, y'understand, is only a good thing when it happens to other people.  For them, post-secondary degrees are a form of insurance -- with the shiny bonus of not having to front the money for it.  (If you're a home-owner, think about your bank requiring you to buy mortgage insurance to protect them in case you lose your ability to make payments:  It's exactly like that.)

Are all companies so risk-phobic?  Of course not.  The current (U.S.) average seems to be that only about half of software developers hold a CS degree.  It's absolutely possible to get a coding job without checking that box.  Just not at places like Google, of course.  Also, that expensive piece of paper, broadly speaking, is leverage for a higher starting salary (upon which future raises and starting salaries at other companies are largely dependant).

Because any stable company -- the kind we work for when we don't feel like gambling our ability to pay next month's rent on the chance of owning a private island -- is generally large enough to have a candidate-filtering mechanism called Human Resources.

I've had the privilege of knowing some very, very sharp HR folks.  Yet nary a one of them can tell you whether or not my GitHub check-ins are crap.  My StackOverflow score?  That's literally just a number...one without an anchor (Pareto distributions and all that).  Obviously, higher is better.  But what's the baseline minimum?  And what if there was even a baseline?  Think about wine for a second.  It's rated on a hundred-point scale, but its scores (among its self-appointed referees) can be all over the map.  And you can still pay top dollar for what tastes like plonk to you.  But HR's gonna extrapolate from an up-vote count?  Yeeeeeeah...

The thing is, if programming were treated like every other profession instead of the Dark Alchemic Art that it emphatically is not, none of this would even be an issue.  And I place the blame squarely on business.  When you can't trust the standard metrics, make your own.  You need demonstrable coding skills?  Have your current developers put together a quiz for candidates.  There's software for that.  Does this person have language-specific certifications?  Great.  Take a quick peek at the GitHub/StackOverflow oeuvres to see whether they've actually been used.  Do they have a blog?  Do they give any presentations to other coders?  Google is your friend.  And you don't even have to leave the office.  Yet.

Once you have a handful of candidates, get your butt off the internet and meet them.  Preferably in a third-party setting.  Then coordinate interview with those that make the cut in-person.  This is where HR really earns its salary.  While you (or your technical evaluators) are swimming in alphabet soup, they're looking for the social cues:

• What's their body language?  Closed?  Aggressive?
• How do they react when they're challenged/corrected?
• Do they treat people of different genders/ethnicities differently?
• How much of their attention goes to people who were not "authority figures"?
• When talking about previous teamwork, what's the "We"-to-"I" ratio?
• Do they put their feet up on my desk during our 1:1?  (No joke, this legit. happened to a recruiter I worked with.  Needless to write, the candidate was not invited back.)

Of course, I have to wonder why there was even a (public) job posting to fill in the first place.  Employee referral rewards, internship pipelines, on-the-job-training, coding "boot camps," and tuition reimbursement are real, actual things, friends and brethren.  Those are all investments -- most of them not inexpensive.  But, then, so is on-boarding someone whose salary averages $50K+ in Canada...and unintentionally sabotaging an entire team with an incompetent git who looked good on paper.

Sure, the internet is a great (and relatively cheap) way to boost the signal.  But it also affects the signal-to-noise ratio like, whoa.  So the first-line filter (a.k.a. HR) needs some criteria to weed out the self-proclaimed ninjas, rock stars, and unicorns of our Dunning-Krueger age.  Employment histories will list date-ranges and, hopefully, mention the technology stack used by the previous employer.  But there's rarely room to mention how long or how extensively any given technology was used in the field.

The bottom line is that, without training to evaluate code, HR doesn't have the resources to make this call on their own.  At best, HR can do the legwork of plugging code samples into search engines to scan for plagiarism (assuming you care about that).  Lacking proper domain knowledge, they have every incentive to fall back on traditional metrics.  Which includes "outsourcing" the "follow up" / "circular file" judgement-call to the four-star rating-system of (you guessed it!) the good ol' college GPA.

At which point, you (as the hypothetical employer) have effectively lost your right to complain about universities not preparing CS students for real-world coding work.  And fer cryin' in your Double-Double, please don't expect colleges to reward plagiarism.  This world is already too much a kleptocracy, thanks.

Chasms and bridges

Last night's meeting of the local programmers' club (The Moncton User Group) was another departure from the usual lecture-with-Q-and-A format.  This past spring, the MUG "illuminati" threw together a three-person panel of experienced software developers and structured the discussion around the theme of "To Be a Great Developer."  Turnout was phenomenal.  And, after a few "seed" questions (prepared in advance), questions from the audience flowed like wine.


So we tried it again with a different panel, again with excellent turnout.  Which included one lone non-programmer--basically, someone looking to get into the proverbial head of his (hypothetical?) technical co-founder.  (Needless to write, I was overjoyed at the hustle.)

Another thing they don't teach you in Programmer School(TM) is that the words "I'm looking for a technical co-founder" mean "I expect someone else to do all the development without a guaranteed paycheck."  And I'm not necessarily knocking that attitude.  Mainly because I don't buy into the idea that any job should be solely about the paycheck.  (When it is, that's an unconscionable Management #FAIL.) 

For a programmer, there are any number of reasons to step into the alternate-reality bubble of brand-new startup.  Maybe she wants to make a bazillion dollars as a founder.  Maybe she's really scratching her own itch, and the non-technical founder is just there to make the process scale.  Maybe she wants to stick it to a particularly oppressive oligopoly.  Maybe she wants to make something breathtakingly new.  Maybe she just wants full control over her greenfield code.  Maybe she wants the cachet of working for a sexy startup.

Any of those is a perfectly legitimate reason for a garden-variety software developer to become a technical co-founder.  Or, for that matter, join an ambitious start-up at a steep discount.  Which is precisely what the non-technical co-founder is looking for as they hustle an actual business into existence.

But here's the thing:  Once that bargain between the non-technical and technical co-founder is made, it cannot be changed without steep penalties.  And both the technical and non-technical founders have to grok that.

So here's the war-story I couldn't tell last night.  (I moderated the discussion, so it would have been out of line.)  Disclaimer:  Everyone involved has since moved on to other things, so I'm not "tattling."  A few years ago, I was approached by someone I knew only through social media.  "Do you want to change the world?" was the pitch.  Fair enough:  The product hit that (narrow) sweet spot between "disruptive" and "in the public interest."  (Go on...)  There were meet-n-greets and salary-vs.-equity numbers thrown around and blahblahblah.  But then the founder, kicking back at their desk, said, "I want to make a @#$%^~* lot of money."

Whoa there, Nellie:  That's not the horse I saddled.

For various reasons--mostly unrelated and outside my control--our association never got off the ground.  For me, it was an expensive lesson that opened my eyes to the self-involved monomania involved in running a startup.  The lesson which I'm "donating" here, however, is something beyond that.  I prefer to believe that the bait-and-switch chronicled above was not deliberate.  Doing well and doing good are not always mutually exclusive.  I prefer to believe that, too.

A lot of ink (real and digital) has been spilled on the notion that vision, creativity, and commitment (the critical DNA of a startup for which money is the spark of life) cannot be bought.  Fair point.  It's been documented since the 1950s that tying pay to creativity actually makes people less creative.   But what's missing from those essays (of which I am guilty) is that just because those loftier qualities can't be bought does not mean that they can't be sold.

Seems like a contradiction, no?

Let's throw back to good ol' Dr. Maslow and his famous hierarchy.  Except think of each tier as its own separate country--complete with its own currency.

When a person is working strictly for a paycheck, s/he is being paid primarily in the currency of the "Safety" country.  Which, since we came down from the trees and invented trade, means that the currency exchange into the "Physiological" tier is pretty much a 1:1 transaction.  An ample and steady paycheck assures that this person stays comfortably in this zone.  That's normally not something a startup can offer.

However, someone taking a pay cut to work for a hot start-up, by contrast, is being paid at least partly in the currency of the "Esteem" country.  Similarly, someone working to change the world (or to stick it to The Man) is cashing their check at the "Self-Actualisation" bank.

Switching currencies without notice--and especially without paying the exchange rate--is management and leadership suicide.  A mass exodus of technical founders and early hires is thoroughly justified:  Only naifs or morons should expect otherwise.

For instance, when working the traditional (and increasingly mythical) 9-to-5 job, one expects to spend 40+ hours away from the family one might be supporting.  That's the deal.  Beyond that?  Time-and-a-half overtime was at least partly intended to be a penalty for taking away one's time with loved ones.  Similarly, when Yahoo's Marissa Meyer rescinded work-from-home flexibility with no increase in compensation, the furor was completely predictable.  That's the Safety - Family exchange rate in action.  In the case of time-and-a-half, the exchange rate is agreed on.  In the case of Yahoo, it was unacknowledged--hence, the (well-deserved) backlash.

Thus, when a glamourous unicorn startup is acquired by a company with deep pockets, each and every aqui-hire will (rightfully) expect to receive deep-pocket wages.  If, for no other reason that the fact that the startup's "glamour discount" on their paycheck is no longer justified.  Goodbye, cool factor; hello, boring behemoth.  Esteem currency, meet Safety currency.  Cha-ching!

And, finally, there's that idealistic, self-motivating Self-Actualisation crowd with their penthouse view of the hierarchy.  From where I sit, commuting Safety currency to Self-Actualisation currency seems like pure alchemy.  Unless you're Elon Musk, maybe.  Otherwise?  Morality, meet profit motive.  Creativity, meet "...because we've always done it this way."  Spontaneity, meet process.  Problem solving, meet executive fiat.  Lack of prejudice and acceptance of facts, may I introduce bureaucracy and vanity metrics.  It's gonna take a huge payday to cover the exchange rate for all the chips that are cashed at that exit event.

Yet the technical co-founder as well as the early hires have some responsibility for maintaining the integrity of the currencies and their personal exchange rates.  Mostly that involves respecting one's market value and being willing to take it elsewhere, of course.  But also recognising the necessary pitfalls that come with a successful startup.

Geoffrey Moore's Crossing the Chasm details the process of bringing a new-new product (meaning something that didn't previously exist...particularly one that consumers have to actively wrap their brains around) to market.  The "chasm" is the no-person's-land between the bleeding edge early adopters and the outer edges of the mainstream.  In software development terms, that generally translates to going from simply "Make it work" to "Make it secure" + "Make it fast" + "Make it pretty" + "Make it scale."

That all involves more people.  Assuming that the money doesn't run out first, that means more eyeballs on the product and different perspectives on where it is headed.  Assuming outside funding, those "different perspectives" are guaranteed to devalue technical perfection in favour of faster time to market.  And also guaranteed to cramp your style as CTO, even if you're only in it for your share of the jackpot.

As the company scales up, maybe you're brave enough to hire people just as bright and fearless and self-directing as you are.  That's no guarantee that anyone else will be.  So not everyone you work with will necessarily be as motivated and/or talented as the original gang.  And, strangely enough, senior devs are grumpy about on-boarding new-hires when they still have deadlines to hit.  Point new-hires at the wiki?  That's been gathering dust for months.  Maybe they can just jump in head-first via source control history?  Ha!  Not even an Ent could make sense of all those branches.  And oh, dear sweet FSM, not another Slack channel--you gotta be kidding me.  Can I pretty-please just get back to coding The Thing?

(Hint:  Nope.)

And then comes the day when you've busted your rear to make month-over-month profits sustainable.  Which is precisely when the VCs decide that they need "someone to take us to the next level."  Whether that turns out to be a seasoned industry insider or just the douchebro smarmasaurus ex-roommate of one of the VCs, you can pretty much kiss any remaining startup vibe goodbye.

Exactly how much equity will to make up for that in terms of cold, hard cash?  That's not a rhetorical question.  That's a number that should be revisited regularly and often. Preferably objectively, and not merely in the immediate wake of those little twinges you feel at...

• "We didn't think you wanted to be at that meeting."
• "What's our policy/process for that?"
• "Why are you wasting your team's time interviewing candidates?"
• "Can't we offshore some of this?"
• "All the conference rooms are booked."
• "The Board wants to bring in a growth hacker."
• "You need to step back from the code and focus on the team."

If you've ever been part of the transition from scrappy product to pseudo-platform, you might have died a little inside at each of those bullet-points.  Yeah, sorry 'bout that. 

But, as a developer, you get exactly one startup experience before you can't claim that you never knew what hit you.  You get exactly one excuse for naively being caught flat-footed with worthless equity and/or a bank balance that hasn't kept pace with your contributions to the company.  It's probably better if you get it over with earlier in your career, but that's ultimately up to you.

Because your "reward" for bringing your product across the chasm is to turn around and find the bridge burned behind you.  Like I said, all those intangible "perks" living in the upper stories of Maslow's hierarchy can't be bought.  But now they have to be cashed out regardless of whether or not you're ready to sell.  Just make sure that the payout matches your exchange rate.  After all, you might just want to build yourself a new bridge into your next startup.     

Waterfall vs. Agile Development, an illustration from the NB DOT

This post is mostly about the Department of Transportation (specifically the one of New Brunswick), but first I want to thank the Department of Small Mercies for doing me a solid...or two...or three...

I was scheduled for a noon meeting in Moncton today.  The initial meeting announcement listed the location as happening on the campus of one of Moncton's two private one-year colleges.  Which narrows it down to a single street address, but nevertheless leaves something to be desired in terms of precision.

So, having enough sense of the organiser's temperament to allow myself a bit of smart-arsery, I enquired as to whether the vagueness was a test of my persistence/resourcefulness, upon which my admission to said meeting would depend.  It turns out that the organiser is at least my equal in smart-arsery.  Which I naturally took as a challenge:  "Oh, honey, it is soooo on," I thought, resolving to be in the room, greeting him with a wave and a Cheshire Cat grin, when he arrived.

Thus, I left Grande Digue with a little over half an hour to spare.  Outside of Shediac on (westbound) Highway 15, traffic suddenly slowed to the proverbial crawl.  First an ambulance and then a squad car passed our line on the left.  Somewhere past the 29km marker, a car lay flipped on its roof, but the rubber-necking was kept to a minimum.  Including my own, so my Gentle Reader will have to check the news for the details.  (P.S.:  Bonne chance, whoever you are...)

Following a short speed up, I encountered the stretch of road which had been stripped of asphalt during my previous run into HubCity.  Today the asphalt was fresh, a dotted line had been painted down the centre...and traffic again slowed down to < 10km/hour.  At least when it wasn't standing completely still.

And this is where our "illustration" really begins.  Because that freshly renewed stretch of highway had been necked down to one lane for kilometres.  Kilometres of perfectly sound road, missing only the side-line markers and (possibly) the rumble-strips.  With nary a worker nor piece of equipment in sight to justify the buffer-state of asphalt that kept traffic to the pace of a snail on quaaludes.  (And, as anyone who lives where other folks vacation can attest, there should be a Special Hell(TM) reserved for anyone who pulls those shenanigans during Tourist Season.)

In software development, there are two ways of making A Thing (for lack of a better term).

• The "Waterfall Development" school harks back to the assembly line of the industrial past (presumably an artefact of lumping Software Engineering in with traditional Engineering).  Designers hand off to Coders who hand off to Testers who ultimately hand off to whoever packages the code and delivers it to customers.  Henry Ford would feel completely at home in this world.
• The "Agile Development" school hews more to the "throw it against the wall and see if it sticks" line of thought.  Which, surprisingly, is also based on manufacturing principles developed in the automotive industry.  Except that it was done within the limited resources of a scrappy post-WWII Toyoda (now Toyota).

Obviously, both lines of thought have their place--Ford and Toyota are corporate behemoths decades after their founding.  "Waterfall" is particularly suited to leverage repeatable processes under economies of scale.  "Agile" thrives in uncertain markets, especially when the end-product might not even be fully conceived.   And, as with any diametrically-opposed methodologies, anyone who attempts to mix them does so under the cloud of impending disaster.  A Waterfall mobile app. start-up jumping the latest VC bandwagon is doomed; conversely, nuclear power plants are strangely averse to the measure-to-learn religion of Agile.  (Go figure.)

But that mixing of contexts is, alas, precisely what added an extra twenty minutes to a commute that normally takes thirty.

Context:  For my Gentle Readers outside of Canada, New Brunswick is what's known as a "have-not Province," and has been since steam replaced sail.  Historically, various Governments (Conservative and Liberal) have cushioned budget shortfalls with "equalisation payments" to guarantee a minimum standard of public services (notably those related to health care).  But New Brunswick's debt (and its debt to GDP ratio) has crept up under both brand-name parties.  And that's before the previous federal Government decided to jump on the austerity bandwagon.

What with that and the talk (a.k.a. threat) of privatising provincial road-building, it's hardly surprising that the bean-counters have taken over with a vengeance. 

Now.  Road construction is not my domain, we say in software development.  So some of the following will be, to a greater or lesser extent, conjecture.  That being said, I can in all fairness call out certain strong similarities between what I do for a living and how the folks in the bright orange jackets make their gelt:

• We only perform our ostensible "work" between interruptions.  In their case, it's mainly weather.  In mine, it's meetings and administrivia. 
• We can't always trust the infrastructure.  In their case it's a pocket of soggy clay, erosion from wonky grading on the last job, etc.  In my case it's network issues, unexpected upgrades, security holes, what-have-you.
• We can be screwed over twelve ways to Sunday by vendors.  'Nuff said.
• We can be--and too often are--encouraged by the Powers That Be to cut corners and/or kick the can down the proverbial road.
• We have to develop and learn to trust a healthy sense of pessimism to sniff out the edge-cases that could bring everything crashing down.
• We know that nothing is ever going to be 100% perfect 100% of the time -- there will always be "beta" mode as well as maintenance.  More on that later.

And, thus, I don't think I'm going out too far on a limb to say that road construction is--or at least should be--more of an Agile enterprise than a Waterfall enterprise.  A road that holds up under years of traffic is most certainly not made by a paper-pusher in Fredericton.  It's made by the experience and the up-close-and-personal first-hand observation of people whose summers are spent with sinuses full of dust and tar.  Not unlike how a project manager can't necessarily appreciate how many ad-hoc hacks will have to be added to deal with the gawdawful third-party legacy system that the designers never bothered to check before the contract was signed.  [involuntary twitch]

I mentioned "beta" mode above.  A road that's partially open during construction is basically the same thing as an open beta in software development.  And in open beta you emphatically do not wait until the "official" launch-date to release all the bug-fixes and missing features.  Any product beta-tested in that fashion will lose the interest of the influential early adopters (and probably never see the light of day).  No.  You shove those things out the door as soon as QA green-lights them.  (Granted, the province has the upper hand in this instance, because people will always gravitate back to the shortest time between Points A and B.   But my point, I think, stands.)

Yet, whoever was directing today's crew could have easily limited the bottleneck a mere kilometre of work surface and left everything else open to two lanes of traffic.  When that was finished, they could have done exactly the same thing for the next kilometre of surface.  And so on...until either the potholes or budget ran out.  In short--the Agile method would have produced the minimal amount of traffic disruption during the busiest season of the year.

Instead, someone (quite wrongly) chose to operate by the Waterfall method.  Again, this is just conjecture, but my strong suspicion is that that someone assumes that handling the resurfacing in larger chunks allows for economies of scale.  For all I know, they're correct--at least superficially.  And, of course, the Suits luuuuuuvvve their Waterfalls...mainly because they live upstream and it makes them feel more like they're the driving force behind everything.  [eyeroll]

But the problem is that, by my estimate, the entirely gratuitous one-lane bottlenecking cost each and every person about extra fifteen minutes, compared to the length of road actually being worked on.  Every missed appointment, every late delivery, every disgruntled tourist --  those come with a cost, too.  For sure, that cost won't show up on this year's tax bill.  But it will show up in one way or another--make no mistake about that. 

In my particular case, the Patron Saints of traffic lights and 2-hour parking and sheer dumb luck (plus my taste for harmless practical jokes) allowed me to make my meeting just in time.  That, however, doesn't mean that I'm not brassed-off.  I've been on well-run projects and ones that barely ran at all--in both Waterfall mode as well as Agile.  Like I said, they each have their proper context.  And it is a sorry manager (and steward of public funds) who chooses the wrong context. 

The Accidental Internship

In truth, I was planning to post this last Frivolous Friday.  Because, when it comes right down to it, the joke's really on me.

You see a lot of the same faces at various Moncton technology-related events.  However, they're rarely the same faces.  But as with middle- and high-school cliques, you'll find a scant handful of individuals who can comfortably exist in multiple contexts.  In this case, one of those individuals is a student shortly due to graduate from one of the local colleges.

Said college does not require (but will give credit for) what amounts to internships.  Mind you, those are not plentiful even in a booming economy (into which category New Brunswick emphatically does NOT fall). Now, it's stupefying to conceive of a situation in which businesses have abused the system egregiously enough to (gasp!) force a change in requirements--under a Conservative government, no less!.  But that, in fact, has actually happened in Canada.  Thus, we can count on several months of a reality in which unpaid grunt-work is not, in fact, the norm for certain career-tracks.  At least not until the lawyers find all the loopholes and labour conditions disintegrate even further into the stuff of Ayn Rand pr0n, anyway.

For all that, I (as a freelancer) seriously doubt that the dearth of internship opportunities can be blamed on the same oppressive regime which tyrannically imposes a lower corporate tax rate than that of the United States.  No.  The reality is that "branching off" tasks is actually pretty darned complex.  There's the up-front cognitive investment, certainly.  One has to define tasks and metrics, for starters.  Also, to be prepared to do it all oneself in cases of extreme failure.  And Dread Cthulu help anyone who has employees.   Because the same ones who are perpetually "swamped" are inevitably the same ones who "don't have time" to train anyone else to take the load off.  (Yeah, people are awesome, amirite?)

But there's a third barrier to the wide availability of internships, and I'll get to that in a bit.

In the meantime, I have the luxury of not having the second problem.  So when a local college student (an older gentleman with an amiable disposition and ridiculous amounts of hustle) informed me that (despite all his networking) he didn't have an internship lined up, I airily suggested that he make his own with a local non-profit.  Then I (very) briefly outlined a project that's about three or four rungs down on my personal pro-bono "To Do" list.  And followed up with the vague, "Oh, well, if nothing else turns up, you know where to find me..."

That was last Tuesday night.

By last Thursday, he and his partner had decided that they liked my idea better than what they had been working on, and would I care to take a look at the project draft they'd hammered out in the interim? And, oh, by the way, the app. has to be turned in by April 15th...

Colour me wryly amused. But also colour me a bit wiser.  Not about making airy, open-ended suggestions (when I should darned well know better) to ambitious college students.  Pffffft--that's just paying it forward after making my own (second) internship all those years ago.  (Plus, knowing me, I'll always be that kind of stupid anyway.)

Uh-uh.  The take-away for me is if interns don't scare the ever-loving beejeebers out of you, you're in serious trouble.  Because, as it turns out, these two aspiring programmers aren't too shabby.  The UI specs that landed in my Inbox this evening had use cases I wouldn't have thought of until the second (maybe third?) draft.  That's not to say these folks are bound for the next Y-Combinator cohort, but daaaaaaaaaang.

And is that, I have to wonder, what prevents a lot of businesses from pipelining students into their ranks while the latter are still in school.  Make no mistake:  It's emphatically NOT FUN to be reminded of the fact that someone else has the luxury (yea, even requirement) of using the Cool Tools(TM) while you're being paid to maintain boring legacy code with infuriating pay-per-seat software that long-gone manager once scored a sweet discount on.

Sure, you can pooh-pooh their naivité ("Erhmehgerhd--where is your validation code!?!?!?"). But chances are, they'll internalise that lesson faster than even a seasoned coder will absorb how Android configuration files are laid out.   In a world where coders halfway around the globe sell their time/expertise at dime-store rates, it's the ability to, well, triage knowledge that's the key to survival.  Oh, and having some hustle certainly doesn't hurt either.

Be afraid--be very afraid.  And for love of Mammon, on-board some of these people if you know what's good for you.

When Empathy > Technology

Dennis's shirts hang on the left side of our shared closet, mine on the right.  The closet doors are the typical sliding ones, so that when one side is open, the other side is occluded by door.  When the doors are open to my side, light from the window is largely eclipsed by anyone standing in front of it, leaving the job of illumination to anything coming from the left.  On the opposite side, it's the opposite story.

Thus, Dennis hangs up his shirts so that they face the right; I hang up mine so they face the left.  In a logical Universe, we would respect this light-optimised orientation when hanging up each other's shirts.  But even a dual-programmer household falls well short of the Spock/Sherlock ideal.  Alack.

The mayhem and havoc wreaked by misaligned clothing can be quantified in terms of extra fractions of a second required to select the t-shirt whose snark and/or geek culture in-joke best matches our mood-of-the-moment.  A #firstworldproblem if there ever was one, in other words.  But it illustrates the power of personal norms to trump logic (and the instinct to use it).  And, in a way, it makes me despair for human progress as driven by first world technology...or even most first world technologists (in whose number I count myself, btw).

Silicon Valley has been panned by folks as diverse as Valleywag and Startup L. Jackson for burning so many calories turning paper millionaires into paper billionaires while infantilising the twenty-something dudebros who are the face of its culture/ethos.  The first is just what shareholder capitalism is optimised to do.  (The second is just plain pathetic.)  Neither of them can be considered truly "disruptive"--at least not in the net positive sense their apologists would have you believe.  Sure, it's taking bites out of the taxi and hotel industry by socialising the costs of industries formerly held more accountable via regulation.  But, hey, you can't make a creative destruction omelette without breaking a few social contracts, amirite?

It's not even a private sector ailment.  NGOs can (and do) squander resources applying first world thinking outside the first world.  Case in point:  The first attempts to convince Cambodian families to add a lotus-shaped chunk of iron to their cook-pots to reduce/eliminate anaemia fell short.  Follow-up visits discovered the iron being used for other purposes, notably doorstops.  But casting the iron in the shape of a fish considered "lucky" by locals changed the game.  Anaemia has been eliminated in 43% of trial subjects, and a sustainable business model was spawned in the process. 

Moral of the story:  Sometimes it's the users, not the technologies, that have to be "hacked."  The catch is that those of us who are paid to be problem solvers have the instinct to hack technology first.  Don't get me wrong--I'm a huge proponent of usability.  The bigger a technology's side effects, the more incumbent it is upon its designers to make it as impossible as possible to misuse.  I get it.

But the slickest, most bulletproof interface in the 'verse means bupkis if it is A.) Not solving a worthwhile problem, and/or B.) Is too expensive (in terms of cost, infrastructure support, externalised costs, etc.) to use by those who would most benefit from it.

So, to recap, to successfully "disrupt" anything, the designers/developers need to:

1. Allow people to benefit their lives/families/communities in a way that was previously impossible
2. Allow them to do it in a way that doesn't require huge (for them!) investments or later remediation
3. Ensure that misuse is darned near impossible without anything beyond rudimentary training

Put together, that's a very tall order.  To pull all that off that takes great wads of empathy--which starts with the proverbial exercise of putting oneself in someone else's head-space.  (But we geeks are supposed to be the "smart" people, right?)  Alas, empathy (or even self-awareness) is not something I expect to find thick on the ground in a place where more than one techbro has very publicly hated on the problems his very own Galt-couture has created.  If that's a representative sample of the "thought leadership" in the culture of disruption, that culture is bankrupt.  Part of me thinks that, in this case, this latest tech. bubble can't burst soon enough.  Except that it won't move the needle on the culture.  At best, that offers the cold comfort that it won't be so lionised by press and pundit.  With February winding down, I've had enough cold for one winter, thanks.

Exceptional madness

Doubtless, my Gentle Reader has heard some form of the adage, "The definition of insanity is doing the same thing over and over while expecting different results."  It's not a bad rule for nearly all situations, actually.

Problem is, it doesn't necessarily work that way in Software Development, particularly during debugging.

See, when you're trying to reproduce a problem, you want to see the same results after doing the same thing over and over.  Anything else spells extra time and resources.  Second-to-worst case scenario is you'll end up essentially creating a VirtualBox-type simulacrum of the production environment so you can replicate the live conditions as closely as possible.  Maybe you'll end up dorking with the system date, or writing custom scripts to roll back test data to a specific point in time...repeatedly.  For sure, you'll be spelunking in the database, likely scribbling down ID numbers and combing through matrices of data.

Worst-case scenario, though, is that you're never able to reproduce the error, EVER.  Nope, no matter how faithfully you re-create the conditions from the bug report, the gremlin never reappears.  That, mes amis, is The Short Road to Crazytown.

So if you've ever wondered why some programmers (and other I/T folks) have a slightly skewed perspective on the world, this is one of the reasons.  For us, madness lies in the exception, not the rule.  In more than one way.

"Day Two"

Bedtime reading the last two nights has been Erin Kissane's The Elements of Content Strategy, which (on the surface, anyway) is sorta-kinda tangential to what I do for a living.  Simply substituting "data" for "content" doesn't always map in an apples-to-apples way, but one concept definitely does resonate for the career of an application programmer.

That concept is what Kissane calls "Day Two."  It's shorthand for the time after the system (typically a company website) is launched, approved, and everyone settles back in to their "regular" jobs.  In the case of any contractors or freelancers, it's the next gig (or looking for it).  But in the case of employees--at least some--the definition of the "regular" job might have shifted.

Problem is, those shifts are not always recognised, much less budgeted/scheduled.  (And if the consultants didn't hammer that point home during the planning phases, you probably don't want to hire them again.)  Bottom line is that those extra hours of researching, writing, photographing, proofreading, vetting (by the Engineering/Marketing/Legal/Whatever functions of your organisation), etc. do not magically appear out of nowhere.  (Nor, equally shockingly, does the time/money for training people when the launch crew moves on.)

Bigger problem is, no one is surprised to read about those realities.  Yet too often the surprise comes when (through some evil influence or misalignment of the stars, no doubt):

• The company blog has been dormant for a year, plus some fool lost the Hootsuite account credentials, so the Twitter/LinkedIn/Facebook accounts are stale, too.
• News releases are being used as a political football between Legal and Marketing...and ultimately published (late) as convoluted fluff that no one with a shred of respect for the written word reads.
• Whitepapers cite the previous version of the product...and still have the old logo/branding--embarrassing!
• Calls to Customer Service (not to mention social media hissy-fits) creep up because the online help doesn't deal with new products and/or features.
• No one has any idea whether email campaigns are working or not, because who has time to set up A/B testing in MailChimp anyway?
• (My personal favourite) I/T receives cranky calls from Management because "No one's updating the website."  (Don't laugh.  It's soooooo not funny.)

Clearly, that Content Management System was a huge waste, amirite?  We need to find a consultant to re-do it for us--the right way this time, darnitalready!  [insert uber-sarcastic eyeroll here]

Over in my more data-driven world, I'm usually, um, "lucky" enough to see somewhat less acute symptoms of the same disease.  But it still means time devoted talking clients out of wasting their money.

Because the bottom line is that information that can't be captured as part of the normal course of doing business won't be backfilled later.  It just won't.  Anyone who thinks otherwise is delusional.  That's the bad news.  The good news is that you will--or should--be talked out of that by any halfway decent/competent application developer.  (Why?  Because we frankly don't want the fallout and bad karma that comes from letting you do that to yourself.  For ourselves personally and for our industry in general.)

Case in point:  I worked for a company that had to make a whack of outgoing long distance calls--to the point of bringing in part-time help (and the owner's kid) three times a week for eight hours a day.  Before my time, the company had had to fire someone who abused the system by making long-distance personal calls.  For an hour.  Five days a week.  I know for a fact that it bugged the heck out of the company Accountant, because he told me the story twice.

For all five hours of lost productivity plus the long-distance charges add up over 52 weeks, it would have been sheer profligacy to force each employee to log all calls--either on paper or even the most user-friendly app. any programmer could devise.  Even requiring the Accountant scan through the month's  dead-tree phone bill isn't a negligible cost (especially as the company grew from 20 to 40 people and acquired two other companies in the process).

But when the afore-mentioned Accountant bee-bops into my office to mention that, hey, did I know that our new phone service provider supplies us with a downloadable plain-text version of our phone bill and is that maybe something I could parse and dump into a database so he can generate reports from it...now, that's a different equation entirely.

Sure, there was the up-front cost of my time (setting up the database, creating a user interface to allow the Accountant to upload the e-bill, and of course setting up the reports).  But after that point, the system could scale up to any number of employees with no extra incremental time required for the Accountant to segment and sort and total the data any old way he needed it. Including, if necessary, importing it straight into his own software. 

That, friends and brethren, is pretty much the gold standard of business automation.  By which I specifically mean that data that would have been prohibitively expensive to manually log was mechanically collected in an easily consumable format (by our vendor).  Better yet, the only business process that had to change was the Accountant having to remember to download the .CSV file and then upload it to our system.  Trust me, he did not complain.

And thus, "Day Two" of that application was just "Day One" of Happily Ever After.  That's how you want your story to end.  And it should end that way if you're realistic about how you're going to capture the data you need to make decisions.  Yes, I realise that it's all too easy to be caught up in the fresh promise of hackathons and project kickoff meetings and wireframes and mockups loaded with Lorem Ipsum.  Just remember that software comes with an invisible fine print that reads "Data not included."

Sane, rational paranoia

So I've been grinding away on a database implementation for a few days now, and today passed a milestone peculiar to database geeks.  That's the one where the number of data tables is surpassed by the number of functions (and stored procedures) written to read, update, and delete that data.

It's the point where I start to feel safe--as safe as you can be allowed to feel, anyway--what with data hanging out on a web server. Once, I thought of that "safe"(r) feeling as mere superstition.  And, to a degree it is.  Just like any situation where you go all-in on one factor.

In short, this flavour of coding is kind of thing logicians call "a necessary but not sufficient condition" for a reasonably safe application.  A lot of different skills and roles play into that.  And, even getting all the technical stuff right means bupkis if the human factor fails.  ("Hi, this is the County Password Inspector calling.  We need to verify that your password is strong enough..."  [insert involuntary twitch])

That being said, there's no excuse for not doing it.  Or for not automatically distrusting every bit of data that wants to be written to your database. 

Thing is, writing database code is just repetitive enough to be boring, but just quirky enough in its logic that I don't automate the process beyond cut-paste-edit.  And once that code is in place as the "gatekeeper" between the main application (web, desktop, API), the main application's code similarly walks the line between "boring" and "can't afford to mail this in." 

Worse, it's slow business.  And not simply because so much is being written from scratch instead of copied and adapted.  This is also when the nitty-gritties that fell through the cracks of the design documents have to be fleshed out.  Even when the developers were part of the design team, this means round-tripping back with the major stakeholders.  Which means they're in meetings rather than coding.  And I can pretty much guarantee you several "Uh-ohs" occasionally punctuated by the more serious "Oooooops."

Which is why it can seem frustrating to the (non-coder) manager that resolving questions last week spawned even more questions this week.  That means your developers will spend even more time in meetings and less time doing what they're nominally paid to do.  And as a developer watching the original milestones loom (and possibly slip), it can be awfully tempting to take the short-cuts.  By which I mean querying, and (far, far worse) updating and deleting data directly in the web code. 

Now, I don't have any proof whatsoever, but I would not be in the least bit surprised to learn that those sorts of shortcuts were behind last month's VTech hack.  Because the smoking gun that left the information of 6.4 million children and adults exposed was a SQL injection hack.  "What's a 'SQL injection hack'?" a non-coder might ask.  I'll let "explain xkcd" well, explain it, because A.) He does it better that I did, and B.) Talking about SQL injection and not linking to the iconic xkcd comic (which I really need to get on a t-shirt)  is like going to RenFest and not making a single "Holy Grail" joke.  It just isn't done, mes amis.

Like I said, zero proof of my hypothesis.  Whichever way, though, that's bush-league work.  Let that sink in for a second:  I'm a freelance coder working out in the wilds of Grande-Digue, New Brunswick, and even I roll my eyes at that kind of sloppy naiveté.  Because SQL injection isn't half so much a technical problem as it is a human one.  And, honestly, if you have millions of customers, you can afford to hire solid, experienced, disciplined programmers, and let them do their jobs.  Which involves indulging the twitchy spider-senses developed from years of painful mistakes.  Normally, you'll only find that level of paranoia in ammosexuals and StormTrumpers.  But programmer twitchiness the sanest and most rational paranoia you'll ever encounter.  Trust it.

Quality isn't just another value-add

Previously, I mentioned that the Q-and-A period at this past Tuesday's Moncton User Group meeting ("Security Enterprise Architecture for Developers") basically resulted in two epiphanies for me.  The first, and more junior, one I riffed on during the previous entry.

My question to Jamie Rees had to do with "selling" security's value to your client as part of the application development process.  (Because we all know we should make apps. secure from the ground up, right?  But, then, we also know that we're supposed to floss every night, too.  And we all know how that plays out for most people.  Your faithful blogger included.)

I was thinking of I/T security in terms of risk management.  To wit:  A data breach costs money.  If data related to financial information (credit card numbers, Social Security / Social Insurance numbers, bank account numbers), the company whose data was leaked is typically on the hook for years of credit monitoring for each person affected.

Then there are the lump-sum costs.  Things like the hit to customer goodwill (which sounds really squishy, but there are accountants who specialise in quantifying that in hard cash).  Finding and patching the weaknesses in the system does not come cheap either.  Depending on the industry, third-party audits might be required.  And if the security lapses were super-egregious, heads will roll, which entails (at a minimum) the costs of hiring and training.

So I figured that this could be gelled down to a simple formula:

Average cost per breach * Likelihood of breach per year = Annual risk

If that "annual risk" (quantified in dollars) is greater than the budgeted amount for security in the Statement of Work, it should be a no-brainer, right? 

Jamie Rees had a few thoughts and suggestions, including the nugget that in security more than anything else, you have to protect yourself from entropy.  Because waiting until a crisis to fix a hole means that you will focus on that crisis alone.  But once that energy's expended, organisational fatigue will guarantee that there will few (if any) resources spent on proactively preventing the next crisis.  (Sound familiar?)

But as I was digesting this all down for my notes, someone else raised a hand and asked the question as it should have been phrased in the first place:  "How do I sell my clients on security without selling fear?"  And, wham!  Synapses linked up, proverbial light bulbs went on.  (For all I know, the heavens opened to the sound of angel-choirs.  But Suite 201 of the Venn Centre is really, really well-soundproofed, so don't quote me on that.)

For the record, Mr. Rees's answer boiled down to mapping security to the project goals.  (Like, I might add, y'do for everything.  We're All About the goals, not the features here.) 

But what hit me was security, really, is just another facet of Quality Assurance.  A very specific facet, it's true--and one perhaps almost large enough to overshadow its general category.

But the thing that's Quality Assurance has proven over and over since Dr. Deming pioneered the discipline is that quality ultimately pays for itself.  Namely, because focusing on quality forces you to take a hard look at your organisation and its processes.  A relentless focus on quality allows far less room for the politics of personality--which includes the always-regretable "rock star" culture.  And it has no mercy for the "But we've always done it that way" argument.

So, when pitching my services to future clients, you can bet that I will be pointing out how developing an application for their business buys them process consulting from an unbiased 3rd party as part of the package.  And all for the low, low cost of higher quality. :~)

A red, green, and blue silver lining

The Arduino platform was created more for design students than professional code-slingers.  Which is cool -- that's a noble rationale, actually.  But it comes back to bite in one way.  See, the folks who adapted its (C++-ish) programming language from the Java-ish "Processing" language aren't really able to support one reality of the modern programmers life.  And that's unit-testing. 

Again, I'm not criticising, because as it turns out, it's sort of a net win.

But first some background/terminology for non-programmers.  "Unit testing" is the act of testing the smallest possible chunks of one's code.  In modern development environments, you tend to write a function hand-in-glove with its test.  The test defines what the expected outcome is for any inputs set.  Then you (or some more automated process) runs the test against your actual code and verifies that the function did what it was expected to do.

(Aside:  Later during the application development process, there are other forms of testing, such as integration testing--did your feature break somebody else's function?--plus performance-testing, and vulnerability scans, etc.  For the purposes of this blog item, we're only focusing on unit-testing.)


In the Arduino world, which relies on the micro-controller taking input from physical sensors, or outputting to physical widgets, simulating that in software would be a boil-the-ocean endeavour.  That's mainly due to ever-growing number of widgets that are compatible with the Arduino.  For a community-supported foundation running on the proverbial shoe-string, that's too much to ask.  And, in any case, I think I can safely say that the community would muuuuuuch prefer to see those limited resources devoted to the core platform.

So for a complex project that involves multiple widgets, one solution is to write your code as separate projects, test it in a more atomic (meaning indivisible) fashion, and roll the tested code into the master project.  For example, my "master" project is a lighting system for the Office Finches.  There are a number of elements that go into that:

• Two sets of bright white LEDs that are controlled by an integrated circuit because the Arduino itself doesn't have enough "pins," (i.e., input/output ports) for the number of lights needed.
• One triplet of red, blue, and green lights that can fade in and out.  With 256 possible brightnesses available for each LED, this comes out to over 16.7 million combinations of red, green, and blue.  The idea is to gradually fade these colours in and out to compensate for the lack of full-spectrum daylight.
• A real-time clock to determine what time it is to turn the lights on in the morning and when to turn them off at night.  (The Arduino, having a fairly primitive microcontroller, does not have an internal clock in the sense that we know it.)
  A passive infrared sensor that is activated (only in the dark) to determine whether one (or more) of the Office Finches has fallen off her/his perch.
• One triplet of "soft" white LEDs to be used as an "emergency" night-light.  They are gradually raised if motion is detected by the infrared sensor over a few seconds, and gradually lowered when the finches have settled back in.
• A photo-sensitive resistor to determine whether it's dark enough to warrant the emergency night-lighting.

As I write, I'm testing the red-green-blue lighting.  The "night-light" feature has been tested, as it was the nucleus of the whole setup.  Tomorrow will probably be devoted in part to deciphering some really old (in computer years) documentation for the real time clock and setting that up for unit-testing (again, in a separate project).

Normally, having multiple copies of the same functionality is frowned-upon in software development.  The reason being that it means that you have to remember to deploy bug fixes or improvements across those copies, which costs time for the coders as well as the testers.

But in this case, I rarely modify the "test" copies of the code once they're verified and rolled into the master project.  Which leaves me with bite-sized bits of single-function code that can be used as reference for (or imported lock-stock-and-barrel into future projects.  As long as I name them descriptively and document the functionality (which of course I do--'cuz that's how we roll chez fivechimera), it's All Good.


In this case, what I'd normally consider a "primitive" lack of testing infrastructure turns out to be a net win.  It's another one of those things they don't teach you in Programmer School.  That's not the point, after all--their job is to mold you into a cog that can be plugged into the machinery...at least for the first year or three.  But eventually, you figure out when and where "the rules" can (productively) be broken.  That's one of those career inflection-points where you slough off another bit of your "programmer" skin to reveal the "software developer" underneath.

Sax and Violins

Okay, not really.  No violins, anyway.  But Dennis did follow through on his persistent whim of taking up the saxophone.  Last week he picked up a used one and just now is starting to get a feel for the reed and stops.  "What's the 'Stairway to Heaven' of the sax?" I wondered out loud as he was assembling the sax and clipping on the neck-strap.

Neither of us had a good answer.  Which at first surprised me--I mean, doesn't every instrument have its own Stairway?  For instance, the piano has "The Entertainer."  Drums have the solo from "Inna Godda Da Vida"; the harp has "The March of Brian Boru," and bagpipes "Scotland the Brave." But nothing comes to mind (my mind, anyway) as the calling-card of the saxophone.  Except maybe the theme of The People's Court.  Or possibly a Kenny G pastische.  But, then, it's not like I could carry a tune in a two-handled bucket, so what do I know?

But then it occurred to me that, any number of non-musical skills have their own Stairway.  It represents an inflection-point on the learning curve--namely, the spot where the student can start feeling confident about being competent.  Unsurprisingly, a software developer is no different in that respect.  Particularly when the developer can expect to be in perpetual student mode, scrambling up at least one learning curve at any given time.

For instance, in mainframe-based systems (meaning text-only terminals--or, even more retro--green-bar paper), the Stairway app. was something like an accounting report crunched from flat files.  (Mercifully, I haven't had the tedium of [shudder] counting columns, specifying output formats, and fretting about data overflows since Bill Clinton and Jean Chrétien were in office.)

Likewise, back in the days of Visual Basic/C++, an angel got its wings when you deployed a multi-form app. that shuttled data back and forth to some sort of permanent storage.  (Alternatively, outside the Microsoft Universe, it likely involved Lotus Notes.)  As pure client-server topologies went out of fashion in favour of the web, so (mercifully) did this skill-set (most especially debugging your way through "DLL Hell.").

Before 21st century content management systems, having a home-brew collection of HTML pages for photos of your pets, vacation photos, and a mouldering blog was the Stairway of web programming.  Or, if you were coding for a business, it was an online catalogue with a shopping-cart duct-taped on.  (Nowadays, in this age of Wordpress, all bets are off...but if it doesn't involveHTML5 plus jQuery and/or AJAX, you might still be a n00b.)

On the server side, the Stairway once was any database-backed application.  While that's still the bread-and-butter of many developers, although with the emphasis on REST, it has more of a roll-your-own-API kind of feel to it.  Double that if you're providing/fielding data that could be consumed or produced by a variety of devices.

For mobile development, it seems to be the venerable list app. with cloud storage, drag-and-drop functionality, and probably some cool icons for classification.  (Disclaimer:  I'm not beyond the "Hello, Android" phase m'self, so don't take my word for that.)

Database?  If you're using a standard relational database, you should know your way around a stored procedure (with input and output parameters) that punches at least two of the SELECT, INSERT, UPDATE, or DELETE buttons.  Bonus points for advanced use of aggregate functions, conditional sorting, or pagination of results.

And, finally, in the strange world of physical computing, things get real when you have to power at least one of your widgets with a supply that's not the Arduino / Raspberry Pi / Beaglebone / Etc.  Extra credit for using interrupts or making it talk to another device that's not the PC that programmed it.

Obviously, there is a world full of other tunes to play with any instrument.  And now a solar system of things (given that humans sent a camera-spaceship out to Pluto and all) for coders to work at.  But just as musicians don't become (or stay!) musicians without practice, so it is with software development.   (Although, significantly, I have yet to see a title like Learn the Trombone in 24 Hours in the bookstore.  And, of course, there's no such thing as Autotune for programmers.  Grrrrrrr.)

My point is that when you buy an album from an artist or band, you're not actually paying for the individual notes or even, really, the songs.  You're paying for a bit of the inspiration that made them tackle those particular songs in the first place.   You're paying off the equipment.  You're paying for the collaboration of many talents.  You're paying those who mentored them, either directly or indirectly.  And, mostly, you're paying for countless hours of experimentation and error, for "Just one more try and we can call it a day" all-nighters, for head-banging frustration and moments of sheer hopelessness.  In a word, you're buying craftsmanship (and the commitment it requires).

And, although I'm not remotely musical, that sounds remarkably like software development.