Digital rubbernecking

As a programmer, I write a fair amount of code that is paranoid--specifically, of anything coming in from the Web.  There is also the added overhead of dealing with encrypted data--passwords, email addresses and the like.  The rest I more or less leave to the folks who set up the servers on which my code and data lives.  Ditto the folks who set up the routers and networks and who invent/improve the encryption algorithms.

That's not to say that I'm not fascinated by issues around security and cryptology.  It's just that I know that I have no aptitude for it--particularly what you'd call "thinking like a hacker."  And hacking-post mortems are like candy for me.

Which, in the wake of last week's Sony mega-hack, basically makes me a rubbernecker.  (In my defence, I don't rubberneck in real life; gawping at disasters online doesn't slow down the traffic or hinder first responders.)

Oh, and is this ever a train-wreck.  Partly, it's the sheer scope.  Thirty-eight million files stolen--some of those files whole databases. 

• Movies leaked to torrent sites before their release date
• Scripts for movies not even in production yet 
• Source code--presumably for games
• Legal assets like contracts, non-disclosure agreements, etc.
• Salaries, including highly embarrassing discrepancies in executive level pay
• Human resources data, including social security numbers, addresses, birthdays, phone numbers, etc.
• Sales and financial data going back years.
• I/T infrastructure maps, complete with security credentials

Worse, Sony's own Playstation-related Amazon cloud servers were apparently being used to distribute stolen data.  Ouch.

Also, though, there was the initial blank-wall response, and now the possibility of fingering the wrong wrongdoer.  North Korea was the prime suspect from the get-go.  That assessment has been disputed and even criticised by the infosec. community, but that's Sony's story and they're sticking to it.  You have to admit, being targeted by a rogue government makes for better security theatre than falling victim to an inside job carried out by pissed-off plebeians.

Oh, and passwords weren't encrypted and the hackers managed to nab SSL root certificates that won't expire for years?  #headdesk

It's impossible not to look, right?  There are just so many flavours of "screwed" involved here--for the short-, medium-, and long-term:

• Revenue lost to piracy
• Further revenue loss if said pirated content sucks and no one wants to pay to see it
• A pretty-much-unquantifiable loss in competitive advantage to its competitors in the entertainment and gaming industries
• Equipment and staffing costs for scanning, then scrubbing or replacing every single computer currently on possibly touched the network
• Nothing short of an identity theft nightmare for thousands of employees and contractors:  Sony footing the bill for any reasonable amount of credit-monitoring and remediation will easily run into the millions of dollars
• The productivity-killing morale-buster for employees now freaking about their current job or their future credit rating
• Possible (probable?) massive class-action lawsuits, particularly if North Korea doesn't turn out to be the villain after all
• The inevitable stock price bobbles, particularly as the after-shocks play out

One hopes that, with all those hits to both sides of the balance-sheet, Sony can scrape together the cash to build stronger, higher walls between its data-compartments.  (Translation:  One hopes that Sony--all historical evidence to the contrary--has learned its lesson.)  As the Forbes article mentioned, a breach for Sony's movie division should theoretically have had zero impact on its PlayStation division.  Unless this was a very carefully-timed parallel attack, that sort of information-bleed across departments (e.g. HR and Legal), not to mention across whole product divisions, is straight-up inexcusable.

If it sounds like I'm blaming the victim, I am--but only sorta-kinda.  Yes, it's tempting to see this as karma for a company that had no problem infecting paying customers with malware--basically using them as conscripts in their battle against piracy--thus leaving them open to other hackers.  And, honestly, Sony's response when the news broke might just be the douchiest thing you'll read all day...assuming you're not following Timothy Loehmann / Daniel Pantaleo apologists on Twitter, of course:

NPR was one of the first to report on the scandal on November 4, 2005. Thomas Hesse, Sony BMG's Global Digital Business President, told reporter Neda Ulaby, "Most people, I think, don't even know what a rootkit is, so why should they care about it?"

Obviously, I don't work for or at the company, so please don't think I'm speaking with any evidence-based authority here.   But the circumstantial evidence points to a management mindset in which security was viewed as an expense to be minimised, rather than an asset to be built and leveraged as a competitive advantage.

If true, investors and other stakeholders should take that cavalier attitude--toward their own crown jewels as well as the personal data of others--as a sign-post on the road to extinction. 

Because ultimately, Sony lives in a fully digital world.  Movies no longer exist as spools of celluloid.  Except for audiophiles, 21st century music is not served up on fragile black vinyl platters.  Most games do not play out with wooden/plastic/metal markers on cardboard these days.  The upside of that world is that copies of intellectual property can be made for mere fractions of pennies.  The downside of that world is that copies can be made for mere fractions of pennies.

Playwright GB Shaw claimed that because the "reasonable man" adapts himself to his environment while the "unreasonable man" adapts his environment to suit himself, all progress must therefore be driven by the unreasonable man.  But that assumes two finite ends of a continuum--a continuum that ignores the possibility of unreasonability shading into delusion.  

Further back in time, the earliest tragedy tracked the ruin of the great, often precipitated by the hubris with which they met forces or events beyond their control.  You'd think that an entertainment company would take that wisdom to heart.  The warnings of Euripides and Sophocles ring true even today.  But companies like Sony bear no resemblance to the travelling companies of players in centuries past.  They're little more than accounting machines, slicing revenues into royalties and residuals. 

But you're smart enough to actually listen to your security folks, am I right, Gentle Reader?  Please tell me I'm right.  Because as much as I do enjoy a good hacking post-mortem (in the same way some people enjoy a good murder mystery), I'd really rather not be rubbernecking at the hacking of someone I know.  Thanks.

Two styles of product development

Whew.  That was a close call.  For a few minutes there, I thought that the house had also eaten James Webb Young's A Technique for Producing Ideas.  (Mind you, I can't find the Penguin History of Canada when I need it, so the house still has some 'splainin' to do.  But that's another story.)

I have a librarian friend who--unsurprisingly--organises her home bookshelves according to Library of Congress numbering.   I'm not so professional m'self, but even so, my History shelves are parsed according to a system...albeit one which likely makes no sense to anyone else.  And the delineation between "literature" vs. mere "fiction" admittedly tends to factor in book size to an inordinate degree.

But given my usual categorisation instincts, the fact that I didn't immediately think to look for Young's book in the "software development" neighbourhood is disgraceful, truth be told.  Particularly as that's also where Strunk & White and a dot-com-vintage Chicago Manual of Style live.  (Anyone who thinks that being a software developer starts and ends at the bytes is--in Web 2.0 parlance--"doin it rong."  So sayeth my bookshelf:  Your argument is invalid.)

A Technique for Producing Ideas is a slim slip of a book--almost a pamphlet on steroids, really.  It dates from the advertising world of the 1940s--notably before "the tee-vee" became the most valued fixture in America's living room.  But even a grab-your-belt-and-fly-by-the-seat-of-your-pants autodidact like Don Draper would have known it chapter-and-verse.  And it's no less relevant today, when all we First World pixel-pushing proles (allegedly) need to do to hose the backwash of globalisation off our blue suede shoes is "innovate."  (This is where I'd love to link to Rory Blyth's brilliant, scathing "Innovidiots" blog-post, but it looks like it's offline indefinitely.)

Absent Mr. Blyth's take on the subject, I think our biggest problem with the term "innovation" is its intimidating suggestion of the blank page.  And I don't think I'm making a straw-man argument when I say that, popularly, innovation is too often conflated with creating something ex nihilo. Intellectually, you can look at the portfolio of the most valuable consumer products company on the planet (Apple) : Graphical user interfaces, MP3 players, smartphones, and tablet computers--and know that Woz/Jobs didn't invent a single one of them. 

That insight doesn't necessarily help when you're staring into a looming abyss of enforced downtime--yay, holidays.  It helps even less to remember that Sir Tim Berners-Lee invented the HTTP protocol on Christmas Day.  No pressure there... [grumble]

So to bring things down to the scale of a manageable metaphor, you mainly just need to decide whether you're ultimately the waffle-iron or the crock pot when it comes to making something.

Waffles have the advantage of being very specific--anyone who's been by the grocery story freezer case should have the basic idea down.   But the parameters, to a certain extent, are relatively fixed:  Starch--typically flour--for body, eggs for structure, some sort of leavening (typically baking soda/powder or yeast) for loft, and milk to make the batter pourable.  Too much of one thing and you could have a weird looking hockey-puck or (literally) a hot mess.  Moreover, modern electric/electronic waffle irons typically impose limits on temperature.

Within those basic parameters, however, you can make some amazing waffles.   (In my world, read "Dennis" for "you.")  Making a "sponge" of yeast-leavened batter the night before, and only adding the eggs in the morning, for instance, makes for a revelation in texture.  Likewise, eggs can be split into yolks for the main batter, while the whites are frothed and gently folded in afterwards.  A touch of vanilla or almond extract?  Yes, please.  Topped with lingonberry syrup (because you live close enough to Newfoundland/Labrador that it's a staple in Maritime grocery stores)?  Bring it.

Waffles are incremental innovation in a nutshell.  Evolution, y'understand.

In contrast, there's the crock pot.  True, milk and/or eggs probably won't be staples of most recipes.  But apart from those, you have a lot of latitude...assuming you respect the laws of Physics.  A crock pot will happily simmer organic vegetarian vegetable soup all day.  A crock pot will just as happily caramelise cocktail weinies and bottled BBQ sauce into artery-clogging, potentially carcinogenic ambrosia.  A crock pot doesn't judge. 

In tonight's metaphor, that latitude is what pushes the crock-pot toward the "revolution" end of the invention spectrum.

I'm not particularly partial to either--in fact, I'm delighted when an idea that I consider commoditised is successfully re-invented/re-imagined.  LCD monitors, LED light bulbs, thermostats, etc. 

But whether you ultimately choose to make waffles or some slow-cooked goodness, the end-goal is the same.  Sure, maybe the first few attempts you'll end up feeding to the dog or what-have-you.  But ultimately, you have to muster the confidence to serve it to company.  Because just as there is no art without an audience, there is no invention without an end-user.

Silly Saturday, 2014.11.29: Nerd vs. Snob

Dennis & I bottled a kit's worth of red wine last weekend, a blend of Shiraz and Cabernet Sauvignon.   Unlike (most) whites, reds typically need a little time to settle into their new digs.  Our future dinner-companion was no exception.  "The fruit and the tannins really haven't melded yet," I pronounced after a sampling sip, "Does saying that make me a wine snob?"

"Yes," pronounced Dennis.  And I laughed, because I knew he was rattling my cage.  (He has standing orders to shoot me if I ever become a wine-snob, and I know darned well that he'd be too sneaky to let me know what was coming.)

I will cop to being a wine nerd...or at least a wanna-be wine nerd--no question.  But it wasn't until a bit later in the afternoon that the difference between wine snob and wine nerd really occurred to me.  What's more, I think that my nerd-snob distinction pretty much applies to anything about which one can be a nerd or snob.

Simply, this:  A nerd tries not to let their judgment interfere with learning; a snob tries not to let learning interfere with their judgment.

That's not to say that a snob won't keep up with the material; it's just that their grading-system is pretty well set for life.  And it's also not to say that a nerd doesn't have standards.  "Two-buck Chuck" is still plonk.  And over ice?  [insert uncontrollable twitching]

The flip-side of an old engineering adage

The description of software development as an "engineering" discipline is, to me, one of those "for lack of a better term" bits of taxonomy.  Sure, there are marked similarities.  In an increasingly networked world, it can truly be said that lives are riding on things working as designed--even when those "things" are merely electrical impulses transmitted between or stored in bits to silicon or magnetic platters.

There's another area where software engineers and all other flavours of engineers certainly do overlap.  That's in the common adage, "'Better' is the enemy of 'done.'"  In management, it's the mantra of those who have to keep an eye on cash-flow.  Below management level, it's the mantra of people who have this filthy habit of wanting to spend time with their families and/or significant others.

Don't get me wrong:  I'm totally about 40 hour workweeks and keeping the company solvent.   I consider anything less an #epicfail on the part of management.

Yet, what rarely (if ever) is addressed is that the adage has an equal-and-opposite truth:

"Done" is the enemy of "better."

If you didn't instinctively grok the essence of that, I can pretty much guarantee that you will the first time you have to get Version 2.0 out the door.  All those corners you had to cut?  They're still as sharp as they ever were.  All those values you hard-coded as 1:1 relationships because you didn't have time to populate association tables?  Consider them diamond-hard-coded now.   Yeah--have fun dynamiting those out.

Now, I would never say that those first-iteration shortcuts were ill-judged.  After all, this is Version 1.0 we're talking about.  One-point-oh is a unique and invariably rude & mercurial beastie.  Version 2.0 is our attempt to domesticate it.  Flea-dip.  De-worming.  The dreaded trip to the vet's office.  If we play our cards right, it won't eat any (more) couch cushions.  If we're very lucky, it won't lick its nethers in the middle of the living room...at least not while company's over.

Problem is--and oh, Friends and Brethren I confess that I also have the stain of this sin upon my soul--too many times we don't take Version 2.0 as seriously as we do 1.0.   First generation products are castles in the air that have been successfully brought to earth.  That's a massive and commendable achievement.   But thinking of Version 2.0 purely in terms of "features we didn't have time for in Version 1.0" is not a forgiveable sin for anyone who aspires to the title of "Software Engineer."  After all, no sane engineer would dream of adding turrets and towers to a castle built on sand.  

For programmers, the work authorisation for Version 2.0 is an opportunity to pay down some (technical) debt, not just wear the silver numbers off a brand-new debit card.  And in actuality, I'm preaching to the choir for the vast majority of programmers.  It's the folks who commission programmers to make new stuff for them that I'm hoping to convince here.

Clients:  Your programmers saved you a wad of cash up-front when you weren't sure whether that wild-haired idea you had on the StairMaster would actually pan out.  But its weekend of garage-tinkering in its boxer shorts is done; let's get this thing showered, shaved, and dressed for real work.  Don't be surprised when that takes extra money and time.  Whether you were aware of it or not, you're the co-signer on the afore-mentioned 1.0 debt.

That probably comes off as sounding brutal.  But I can assure you that it's a mother's kiss in comparison to the sound of a potential customer clicking on a competitor's product instead.

When sorcery and software don't mix

It's been nearly a decade since I had to wear the "Sys. Admin." hat full-time, but apparently the karma that goes with that role hasn't entirely worn off.  Today was the first time I realised that this can sometimes be a mixed blessing.

Let me back up for a bit and first define what I mean by "Sys. Admin. karma."  Let's say you work in an office environment and your computer is, for lack of a better term, "being stupid."  Maybe you've already rebooted, or maybe that would throw the proverbial monkey-wrench into your current workflow.  Either way, you're hosed, and it's time to call in someone whose job it is to un-hose you.

Back in the Day(TM), in another country, in another industry, that would have been me...when I wasn't babysitting servers or refurbishing workstations for the new folks being shoehorned into a rapidly-expanding staff.   Now, my office was tucked away from most of everyone else--probably because I shared it with four servers and, hoo-boy, were they loud.  So by the time I'd crossed my floor to the stairwell and trotted over to the far end of the lower floor, the problem had a good chance of fixing itself.  Memory/CPU usage had stopped spiking, a file lock had been relinquished, whatever. 

Being Upper Midwesterners, my co-workers would typically apologise profusely for "bugging" me, typically after swearing up and down that the problem had been there just a minute ago, really-and-for-true.

That's Sys. Admin. karma.  The phenomenon is not limited to I/T of course--as anyone who has had their car's disconcerting squeak/rattle disappear on the way to the mechanic can attest.

When I changed jobs back to developer, I was spoiled for several years by having The Sys. Admin. Who Walks on Water there.  But for my own projects, particularly after going freelance, I'm pretty much on my own.  So it was today after I was fresh off a status call with a client.  We'd both noticed that there'd been no actionable traffic to/from his web app.  That's weird for a Monday.  But then again, it's a slow week in the U.S. due to the Thanksgiving holiday.

Or so I rationalised.

For a short while.

Inevitably, paranoia got the best of me, so I logged in to peek at the database.  Sure enough, data was still being crunched; it's just that nothing had tripped the required threshold.  So I emailed the client to let him know that, so far as I could see, everything was cool.

Not fifteen minutes later, the app. spit out a couple of emails indicating action items.

It was pure coincidence, of course.  (No, really.  Pinky-swear.)  Yet the human mind could easily translate the juxtaposition of me telling my client that everything was cool and the sudden appearance of app.-generated emails into a cause-and-effect relationship. 

Technically, that's synchronicity.

But--is that necessarily a bad thing?  From an outside perspective, I only had to log in, barely poke around, and the inscrutable Server Gods blessed the client with a couple of emails.  Magic!  w00t!  Five points for Hufflepuff!

Problem is, the root of magic is the audience seeing an action (or set of actions) result in something seemingly impossible...or at least counter-intuitive.  In the absence of complete information about inner workings, folks will construct their own narrative.  Professionally, the magician has two jobs:  1.) Conceal the actual process between the action(s) and results, which includes 2.) Preventing the audience from forming unwanted hypotheses about cause and effect.  

But since the days when we stared into the darkness outside the firelight in hope that the darkness wasn't staring back at us, our species has mastered few skills quite like narrative-generation.  (Which probably explains why statistics--more honoured in the misuse than the use--have a bad name.) Thus, one person's magician is another's charlatan--or, worse, practitioner of the Dark Arts.

In my case, my client could suspect that I quietly fixed some bug under the guise of "sanity-checking" that the app. hadn't stalled out.   And, in the face of suspiciously close timing, I couldn't in fairness call that unreasonable.

Right now I'm trusting to nearly a year and a half's work with said client that he doesn't, in fact, suspect me of server-side slight-of-hand.  Mind you, I do still occasionally take joy in finding the magic in what I do for a living.  But I know that I'll never have the marketing chops to peddle it.  Then again, if I can earn that kind of trust from someone with a very different skill-set, that's a higher form of magic than anything I could coax from a compiler, no?

Frivolous Friday, 2014.11.21: Maslow's Hierarchy for programmers

amirite?

/ \

/   \

/     \

/       \

/         \

/           \

/ Source \

/  Control \

-------------------

/  Debugger  \

-----------------------

/     Runtime      \

----------------------------

/       Compiler       \

--------------------------------

/      Code Editor       \

------------------------------------

- - - - -

* If you weren't required to take something like Psych. 101 as part of your GenEd. requirements, here's the original: http://www.simplypsychology.org/maslow.html

Working "unplugged"

So there's been a bunch of chatter in recent years about reducing distraction at work...at least when we're not being all collaborative-y, getting loopy on dry-eraser fumes and all that knowledge-pollen we're sharing while singing "Kumbaya" in some corporate war-room.

Turning off your cell phone, powering down the IM client, signing out of social media, even checking out of the digital Hotel California otherwise known as email--that's how I usually understand "unplugged" working.

But what would happen if we also pulled the plug on our workstations?(Assuming that they can run off batteries, of course--regular PCs don't take kindly to that sort of thing.)  Human value-systems shift drastically when something previously taken for granted becomes scarce.  I can't imagine that electrical current is any different.

I, working on this 2009-vintage Dell would be lucky to see half the battery life of, say, a new-ish Macbook Air.  But...would that make a difference in productivity?  That's the interesting question.

Maybe, when we know that we need to go heads-down on some chunk of work, we should think about turning that battery indicator into a hourglass.  (And, yes, I'm thinking about that scene from The Wizard of Oz.)  Scarcity clarifies...and while not the mother of invention, is frequently is the midwife.