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.     

The evolution of a contract

Just about a year ago, I contacted a lawyer about overhauling the contract I've been using with clients.  What I was then using was essentially split into two parts:

1. The "legalese" that defined terms, spelled out the conditions under which a Party could "fire" the other, etc.  Basically what contracts are expected to do.  Much of it has been borrowed from contracts I've signed in the past, and translated (as far as possible) into The Queen's English.
2. The "Statement of Work," which was specific to the client project at hand.  It described the work to be done, and then itemised it with the amount of fee allocated to each line-item of the overall deliverable.

The first and main criticism the lawyer brought was that the two documents should be streamlined into one atomic unit.  Fair enough, I suppose.  Problem was, the new version was likewise partitioned into a "legalese" part and a "technical" part.  Without, I might add, any attempt to ameliorate the legalese for the benefit of anyone whose writing skills haven't been demolished by Law School.  No attempt, that is, besides wholesale cutting and pasting of my original verbiage into what looked for all the world like the bolted-together results of a LexisNexis search.

In short, it was a Frankencontract, large swathes of which didn't even apply to what I, you know, actually do for my crust.  Grrrrrrrrrrr.

I made one wholesale revision myself, then made my dissatisfactions known when we reviewed the mark-ups over the phone.  The second draft wasn't as dreadful (or nearly as long).  But halfway through amending its sins, I gave up on a hopeless cause.  No point in paying someone to do their job for them.  Surprisingly  (or perhaps not) I never heard from the lawyer again. 

This week, I pulled out the standard contract I've been using since last year's debacle, and realised, "Aw, Grethor--I can't believe that we never even thought to mention Secure Sockets Layer (SSL)..."  So into the mix that went, and the end of the contract inched (or centimetered, for metric contracts) down on the page.  Sigh.

To re-purpose an old adage, good contracts come from experience, which come from bad contracts.  Or, much worse, no contract at all.  For a freelancer or small business, paying a lawyer for a standard contract makes it tempting to treat it like Holy Writ.  Or The Necronomicon, depending on your view of the legal profession.

But, to me, a contract is more like DNA.  As it should be.  Because a contract is a living document that can, and should, evolve with its business.

Now, I prefer to think that successful business-to-client or business-to-business relationships are the default.  (Because the vast majority of us mean well...riiiiiiiight???)  Failure, then, is what designers and programmers call "an edge-case."  And, while there typically are multiple paths to success (even with detours and construction), the paths to failure are legion.   (Pretty much the opposite of Stairway to Heaven vs. Highway to Hell, when you think about it...)  And so contracts mostly exist to head off edge-cases (or at least to define what happens when a business relationship goes off the proverbial rails).

What's interesting to me, however, is when a business has survived enough mutations of its revenue model to acquire what in biology is known as "junk DNA."  (It's also known as "Non-coding DNA," but the programmer in me takes no small exception to that, y'understand...)  At one point, up to eighty percent of human DNA had no "explainable" purpose.  Later science has emphatically questioned that.  (Not surprisingly, I might add.  Not only does Nature abhor a vacuum, she is also an incorrigible pack-rat.  Honeybees being a case in point.  But don't get me started on that.  No, really.  You don't have that kind of time...) But a certain percentage of it nevertheless is purely vestigial.  (And thus the analogy holds.)

And, of course, the role of parasites in evolution is not to be underestimated.  For good and ill, by the bye.  As it turns out, the absence of nemeses for our immune systems may actually correlate to other problems.  (Because, after all, what's a comic-book superhero/ine without a monologuing super-villain, I ask you?)  Alas, it takes all of one bad actor to trigger a Cambrian Explosion of clauses in the contract of the party acting in good faith.

Yes, I realise that the "Lawyers are why we can't have nice things" meme has been fashionable since at least 1591.  But I would encourage my fellow software developers (particularly the freelancers) to re-think their opinion of contracts.  I've already mentioned edge-cases, which is certainly something that any dev. can wrap their think-meat around. 

But, far more importantly, the entire process of negotiating and signing a contract is an invaluable preview of how the project will likely run.   Just a handful of possible scenarios:

• Client signs your contract without question:  Woo-hoo!  You and your lawyer did a bang-up job with that contract, yes?  Nope.  This signals zero attention to detail on the part of your client.  And it's going to bite you in the butt--possibly both cheeks.  Unless you have a P12+ Telepath on your team, you're screwed.  Get written sign-off on every deliverable, grow a thick skin, and have your lawyer's burner phone on speed-dial.
• Client sends you a contract that they obviously didn't (or didn't want to) read:  Pretty much the same problem as above.  This tends to happen with larger, institutional clients.  Tip-offs included (but are not limited to) references to obsolete technologies.  Tactically, consider it a cry for help and negotiate.  (And, for pity's sake, work your otherwise billable time and that of your lawyer's into the project cost.  You are emphatically not in business to compensate for their flabby Legal Dept.!)  Strategically, consider it an orange flag; bill them incrementally--that place has clearly been infested by bean-counters, martinets, and gold-brickers.  Collect your fee ASAP and don't hand over the IP until the cheque clears.
• Client won't discuss the project with you before you sign an NDA:  Not necessarily a red flag; it depends on how bleeding-edge the idea turns out to be.  You've been around long enough (or at least hang around with people smart enough) to know that ideas mean bupkis without execution.  Unless your spider-senses--by which I mean your personal network--tell you that these folks are working on something very close to your pet projects (or the projects of your existing/potential clients), you're probably safe.  However, you will not be able to use them as a references for rain-making.  Factor that into your pricing accordingly.
• Client pushes back on item/project cost:  Groovy.  They're doing their job.  If they're funded by VC or public money, this goes double.  (If they're funded by VC or public money and they don't push back, write them off for future business...and referrals.  Also, make a note of their names for when they invariably attach themselves to another startup.)  You are ready for this, because you've already crunched the cost-benefit numbers.  (Riiiight???)  One caveat:  If you've already been through a few projects with the client and the push-back isn't a formality, you have a trust issue that needed to be resolved a long time ago.
• Client pushes back on Intellectual Property (IP) ownership:  Also not a bad sign.  Again, you've crunched the numbers enough to know what you're giving up, and you know what they're willing to pay for that.  So it should be an easy call.  Also, you know better than to hand over the work until the cheque has cleared.  So you're not going to budge on that point.
• Client insists on a handshake agreement:  Nope.  Seriously.  Just nope.  Get the heck out of there.  Now.  There are other clients waiting for your help. 

In short, put on your "Sherlock" hat and make a game of it, if that's what it takes to keep your analytical skills engaged on the business side of freelancing.  Because your business exists to survive, not to provide an interesting fossil.

A.B.H.

As with many rants, the thing at which I'm yelling is not actually the thing that cheesed me off in the first place.  For that reason, I'm keeping names out of this.

The Moncton tech. community, like any community, has what's known as "super-hubs" in its network.  These are the folks who pretty much know everybody (sometimes even before being introduced), and whose job--officially or not--is to connect people.  It would be difficult to overstate the time/resources/opportunities that would be wasted if not for these folks, and I look for ways in which I can repay what they've done for me over the last few years.

But with any community resource, its value is cheapened when any-old-body assumes that they can short-cut their way to clients, employees, etc. by basically asking a super-hub to spam her/his network.

As these requests go, today's email was comparatively defensible, and I'm honestly quite happy to note how tight-knit the Moncton and Fredericton tech. startup community is.  No silo-ing or turf wars in sight, and thank the FSM for that.

Alas, something that's been simmering for awhile boiled over.

For anyone who doesn't know me, I'm a freelancer building a fairly niche business and, frankly, I'm still in over my head on where I fit into the local economy...if indeed I fit at all.  And so I've been to a whack of after-hours mixers and lunch-n-learns and business-over-breakfast thingies lately.  And I'm afraid that in the context of such events, I've too often heard the lament that business "can't find" the programming talent it needs in Moncton.

Yet, strangely, the only people I see at the user group meetings are other programmers.  Ditto the classes sponsored by the Cybersocial.  Same deal at the MPL Makerspace/FabLab.  It's like all these non-technical managers/executives are afraid of programmers in packs.  Like there will be a West Side Story-esque suits-vs.-geeks rumble.  Or something.

There are a few notable exceptions.  I know of at least one Moncton tech. company that practically works hand-in-glove with a private college.  Frankly, such pipelining doesn't skeeve me out.  Far better that than the business that expects the government to provide a corporation-coddling tax climate and educated college grads.  And--bless his heart--Dan Martell's advice to would-be tech. entrepreneurs was to (gasp!) figure out where geeks hang out and go look for a technical co-founder in those places.  (Yes, I know I said I wasn't going to mention names, but credit's due where credit's due, yo.)

Clearly, some suits get it.  It's the ones who send out the emails that contain phrases like "We have an immediate need for _n_ developers..." that burn my bacon.

No.

You had that need as soon as you knew that you were opening a branch office.  Or as soon as you put together the project proposal you knew your current staff couldn't support.  Or as soon as you started lunching with VCs.  Basically, as soon as you were fantasising about how you were going to spend your share of the new profits, you, my friend, had that need.  If you now have an "immediate" need, it's loonies to Timbits that you chose to do other things until you absolutely couldn't ignore the most fundamental job a business has.  You're basically the kid who waits until 8:30 the night before the project is due to tell Mom that you have to go to CraftWorld for the supplies.

And so I frankly don't want to hear about the dearth of programmers that you could be standing knee-deep in if you'd bother to get to know them.  Best of all, the programmers who show up to places like Makerspaces and user groups are the motivated ones.  Sure, I've known plenty of very bright developers who prefer to pick up a new technology/framework by reading code and tinkering on their own.  Nothing wrong with that.  But the advantage of mixing with programmers among their own tribe is that you meet the ones who aren't embarrassed to ask questions in front of their peers. 

Look.  Most suits are inherently salespeople.  So I'm going to assume that part of their self-education involved the film Glengarry Glen Ross.  As such, they'll immediately recognise that I'm referring to that scene:  Alec Baldwin's profanity-laden verbal beat-down that includes the acronym "ABC," for "Always Be Closing."  That maps nicely--and without all the F-bombs--to "ABH" for "Always Be Hiring."

Hiring the best of the best means having a the pick of the market.  Which means that you have to know the market in the first place.  Oh, you had your heart set on that 10X full-stack unicorn, but now s/he can't be poached from the once-in-lifetime start-up opportunity?  Womp-womp on you for not seeing if there were any more at home like her/him.  Maybe next time you'll create a job around a person you know will take you to the next level...before it's time to scramble up that hockey-stick curve.  Or, better yet, you'll actually have met all your potential hires face-to-face long before their phone screen.

Start-ups have the mantra, "Get out of the building," which means validating their ideas before they build.  "Get out of the building" also applies to hiring.  Because you can't say that your employees are your most valuable resource if you expect them to magically drop into your org. chart with the right skills at the right time.

Always.  Be.  Hiring.

And, if we happen to meet at any number of these mixers, bee-bop on over and say "Hi."  Now that I have this rant off my chest, I probably won't be too bitey.  Unless, of course, you ask me if I know anyone who's looking for a developer job.  :~/

Playing in a different league

Author/Blogger Michael Lopp (http://randsinrepose.com/) claims that, on a semi-regular basis, he crafts a short-list of people with whom he'd found a company.  Then he folds that Post-it into a small cube and swallows it. 

That anecdote actually came up over dinner chez fivechimera last evening, with both Dennis & I brainstorming our respective lists.  How someone makes the list is actually a bit of a balancing act.  It's a matrix, really.  On one axis is the general skills fit--does this person have chops?  That's the easy part.  The other axis is the price of those chops in the coin of personality friction.  (How often am I going to butt heads with this person?  How many people are they going to drive away by being insufferably right at the wrong time in our trajectory?)

Yeah, I know that all non-geeks (plus a healthy percentage of the geeks I know) are nodding, reliving the pain of every socially inept interaction they've had with that person...maybe even those people.  Uh-huh:  The retentive completionist who passive-aggressively drags on the schedule until their pet feature is ready.  The Tamarian whose Rosetta Stone turns out to be Firefly quotes.  The SysAdmin who clearly missed their calling as a black market dealer.  The "idea hamster" who can't execute their way out of a proverbial wet paper bag.  Et cetera.

But unless you're relatively new in the world of work (or you're extremely unlucky), you know a few who make the cut.  And if you're not as lazy as I am, you keep in touch.  This morning's spike in my LinkedIn traffic was not a coincidence.  Which, to my chagrin, prompted a comparison between last night's brainstorming and fantasy sports leagues. 

Mind you, it's not an entirely frivolous exercise, because it inherently forces one to acknowledge one's limitations (in time and talent).  For example, here's my particular fantasy roster (names omitted):

• Network/IT Support - Yes (with a second-string backup)
• QA - Yes (also with a second-string)
• Graphics and Design - Yes
• UI/UX Developer (web and mobile) - No
• Tech Support - Yes (with multiple levels of backup)
• Project Management - Tentatively yes
• Sales - Nope--and that's the 363.64-kg gorilla of my (hypothetical) staffing problems

But the uncomfortable fact remains that until I have a working prototype with which to pitch the team (to say nothing of potential clients and/or investors), my roster in the Fantasy Startup League is just that--fantasy.  It's not out there, sweating and bruising itself on the ice or the astroturf.  It's not even in the weight room or breaking down video of last week's key plays/misses.  Nope--it's sipping a beer in its armchair, shouting off-the-cuff opinions (which may or may not be founded in reality) at the screen.

The folks out there who are fighting fires, losing sleep, duct-taping, putting the "work" in "networking," rolling the bones--all the while listening for the pacing of the wolf outside the door?   No matter how small the company, they're playing in the big league.  And don't think that I don't understand the difference.

Innovation iconoclasm: Beyond the cult of the start-up

I stalled out about a quarter of the way through Geoffrey Moore's Dealing With Darwin, which has nothing to do with the quality of the book (which is excellent), and everything to do with my ability to be distracted.  Now I'm picking it up again as my "nightcap" reading. 

It kind of hit a nerve when I learned that the office where I spent the best years of my career has been broken up into functional "pods" (for lack of a better term).  That's on the heels of a shake-up that saw a spike in my LinkedIn social circle.  Zo wellz--the silver lining is that it spares me the risk of nostalgia.  I mean, yeah, I can be nostalgic about the days when 20 or so of us were proudly referred to by the boss as "The Island of Misfit Toys."  But we were also working on a scrappy new bet-the-branch-office product then.  That takes a particular alchemy--not mere chemistry, which is far too predictable--of personalities to pull off.

And then at some point, you wake up and find youself and your product find yourself in a more mature market--which is a whole 'nuther game.  That's what Dealing With Darwin is about.  And probably why it's overlooked on most business reading lists.  After all, Moore (and his colleagues) are known for the consulting work that preceded and spun out of Crossing the Chasm.  The latter focuses entirely on growing a product market from the adventurous early adopters to the more sceptical mainstream (by bridging the gap between their very divergent needs).

That early stage company bringing something brand-new to a market with no mental map for what they're making/selling is what (nearly) everyone associates with "innovation," right?

Darwin, however, hammers home the much-neglected truth that there are more species of innovation than the brand-new product.  Things like the following require "innovation":

• Adding new features to an existing product (e.g., a camera to a phone)
• Making an existing product do more with fewer resources (e.g., lower-power computer chips)
• Tapping a new (unexpected) market for an existing product (e.g., Viagra was originally a failed treatment for high blood pressure)
• Up-scaling an existing product/market for higher profit-margins (Starbucks, Apple Computer, Whole Foods)
• Streamlining and standardising supply chains and work-flow (e.g., Ford Motor Company, McDonald's, Dell Computer, etc.)
• Re-tooling work-flows and supply-chains to emphasise quality and reduce the cost of mistakes (e.g. Toyota Motor Corporation)
• Reducing transaction friction/overhead with the end-consumer (e.g., Zipcar, Netflix)
• Abdicating responsibility for labour and safety laws by declaring your employees "contractors" and yourself a "technology platform" (e.g. Uber, TaskRabbit)
• Itemising core services and adding surcharges for them (e.g., airlines, banks)

Okay, so maybe those last two are a little bitey, but that doesn't change the fact that there's a certain level of (ahem!) "creativity" in them, not to mention a relentlessness in execution that has--regrettably--made them the new normal.

The point is that established companies can't rest on their proverbial laurels.  Any good idea will have copycats--some better and faster than others--and the "first to market" advantage has a limited shelf life.  After that, it takes management discipline (and probably no small amount of luck) to stay ahead.  Which will yield higher returns--investing R&D dollars into making a better product, or into reducing costs?  Or maybe (just maybe) is it time to start exiting the race to the bottom and bring that skunkworks project into the light of day?

Those are not easy questions to tackle, particularly with all the baggage and politics of an established money-making track-record.  While individuals may too often throw away tangible good in pursuit of phantoms, organisations are not so often guilty.  Maybe it would easier if we'd more readily recognise  innovation when it wears business casual in Toronto instead of just a Red Bull-stained hoodie in Silicon Valley. 

A funny thing happened on the way to modern English*

One more tidbit from the (ongoing) deep-dive into ancient/classical Rome.

Latin and modern English pretty much agree on a broad definition of "patron."  A patron looks out for something or someone.  hen a customer patronises a business, s/he is interested in keeping it going--perhaps when there might be cheaper and/or more convenient equivalents.  In the days when kings and nobles sponsored writers and artists, they were considered patrons.  (Of course, a rising middle class meant that patronage tended to become more democratic, but the basic tenet still held.)

The resemblance ends there, however.  The definition of patron (and the relationship between the patron and those he patronised) changed a bit over the centuries, but the basic idea ran more along the lines of reciprocal obligations.

Oddly, the patronised were called "clients," which sounds strange to modern ears, because the client in what was considered a socially inferior position--and, by definition, held less power.  It doesn't map cleanly to the later feudal obligations of serf -> minor nobleman -> major nobleman -> king.  But it was knit tightly into the social structure and roman ethos of trustworthiness.

A patron's obligations to his clients, depending on the time, could include financial support, brokering marriage arrangements, representing his client in court, use his influence to shield the client from the tax collector or to right some wrong done to the client.

The client would (most importantly) vote for his patron.  But (again depending on the century), he might go to war with his patron.  Or provide what services he was capable of performing.  He might contribute money to the patron's efforts (political campaigning or religious services).  If the client was powerful enough to have clients of his own, those sub-clients might be put to the use of the patron.

The eye-opening facet of this relationship was that it was binding on one's heirs.  In essence, it became quasi-familial.  Patrons and clients could not testify against each other in court.  If a client died without an heir, his patron would inherit his property.  That freed slaves automatically became clients of their owner was no surprise, but people conquered by a Roman army would (again, in certain points in history) be considered "clients" of the commanding general.  Or the Emperor (which was sometimes one and the same).

Today, the only echo of this relationship can be found in the attorney-client / doctor-patient / confessor-sinner relationship.  All are to some extent protected by law and professional ethics in a way that other business relationships aren't.

(Of course, in I/T, "client" has another meaning entirely.  But rather than a client-patron relationship, it's a client-server relationship, which is where our definitions really go off the rails...)

When you dabble (as I do) in etymology, you're used to meanings outgrowing their words, or sometimes shrinking within them.  And sometimes the meanings almost turn themselves inside out.  As a business owner, I thought it was interesting how the meaning of client transitioned from one who relied on someone more powerful (sometimes for their sustenance) to the person who really holds the power in the relationship.  Thus, client and patron have become almost equivalent in meaning, at least from a business's standpoint.

- - - - -

* A wink to the Zero Mostel vehicle.

Scratching at scale, Part II

So there's an itch.  And it turns out that the most effective way to scratch it is with a computer of some sort, typically a desktop, laptop, tablet, or smart phone.

One of the dirty secrets of software development is that, even in relatively small organisations, the sheer number of users tends to stretch the usage of the software in directions that might not have been anticipated on the whiteboard.

The person (or people) with the initial itch face something of a paradox when designing a software product meant for mass-use.  And that paradox boils down to two contradictory mandates when bringing the product into the real world:

• Commandment 1:  Know Thy Itch.
• Commandment 2:  It's Not About Thou.

Confusing, right?  Actually, it doesn't have to be.  Because really, these commandments are two sides of the same proverbial coin.  Allow me to explain.

In the earliest phases of product design, everyone--and I mean everyone--involved absolutely must understand the itch.  Top to bottom.  Backward and forward.  Inside and out.  No excuses.  Why?  Because misunderstandings make for bad assumptions.  And bad assumptions solve the wrong problems (at best) or non-existant problems (at worst).  And in either case, waste time and money.

In practical terms, that means that the everyone, including the designers and coders, need to be allowed to experience, first-hand, the pain-points.  Even if it's in a shadowing capacity.   Even if they don't actually work at the organisation.  Actually, make that especially if they don't actually work at the organisation.  Mainly because there's no substitute for first-hand experience.  But also because the outside perspective can see past the politics to strip the personalities away from the actual problem to get to its essence.

After that point, it should merely be a matter of implementation, right?  Not so fast.

Software development is expensive--let's not pretend otherwise.  It's expensive in terms of the time the organisation spends on the development process as well as the quoted budget.  Thus, the temptation is always there to leverage that investment by making it available for others.  Those "others" could be different parts of the organisation.  Or they could be working for companies in the same (or a similar) industry.  I've seen it happen both ways.

That's the point where Commandment #2 kicks in.  Maybe the software will do 95% of what these other folks need--but the catch is that the missing 5% is mission-critical.  At that point, the original group has to decide whether or not to add that functionality and, if so, how to fund the additional work. 

Even when the monetary cost is shifted to those requesting the changes, there's also a loss involved--namely a slight loss of control over the product.  It's not logical, but this can be more painful for some than writing the cheque.  But it's understandable--all the work that the original team put into researching, brainstorming, evaluating, testing, training, etc. is something to be proud of.  Particularly when the product is useful enough that others are interested in it.  But now these unappreciative barbarians want to change it!

Again, the reaction is perfectly understandable.  Unshockingly, it even happens to your faithful blogger from time to time.  But that reaction is also the warning that you've strayed away from Pride and wandered into Ego.  See, the process of initially scratching the itch requires checking egos at the door.  In practical terms that meant things like...

• Not taking "That's how we've always done it." for an answer.
• Not allowing office politics to shape the design.  
• Not using information to play favourites.  
• Not pawning off responsibility on those who have no authority.  
• Not postponing tough decisions.

It's time to repeat the process.  Good news!  Everyone involved in the original software development cycle already has practice with this.  Better yet, they probably even internalised the basics of the itch.  All of which can be applied to the new-and-improved-and-ready-for-prime-time edition.

So, in the end, Commandments One and Two really aren't contradictory.  They're both about zeroing in on the pain-points, and making the pain go away.  The shortest route to that more often than not cuts through personality and power-dynamics and especially egos.  Compared to that, the challenges posed by technology should be a breeze, right?

The "lean" economy

There's a school of code-slinging known as "agile programming," which is an offshoot of the "lean manufacturing" pioneered by Toyota in the aftermath of WWII.  One of the most basic tenants is the commandment to "fail fast."  In software, that means getting the most usable features--even in the roughest form--out in front of real users as quickly as humanly possible.  (The terminology is MVP, or "Minimum Viable Product," btw.)

But the most useful part of the "fail fast" mantra is the three-fold assumption that:

1. Failure, at some level, is inevitable.
2. Small, inexpensive failures should be insurance against large, catastrophic ones.
3. Be willing and ready to "pivot" your business model and/or product at the proverbial drop of a hat.

Seriously, it's about as healthy of an attitude toward failure as I've ever seen.  Better yet, it comes from the real-world, rather than "Self-help" woo from the bookstore.

Coming, as I do, from that operational mindset, I have a difficult time stretching my think-muscles around the willingness of big business and government to compound failure by postponing it.  That difficulty is exacerbated by both the money-printing-presses of central banks and the hoarding behaviour of large corporations.  Don Pittis' editorial on "zombie economies" really brought that home yesterday.

Pittis is a little vague on the point of zombie companies in particular.  But what I suspect he refers to, at least in part, is companies buying back their own stock, financed at least in part with artificially cheap money.  Fortune in February noted that large buybacks don't tend to be well-executed by companies for a couple of reasons:

1. They're buying stock at relatively high prices, and
2. They're spending that money in lieu of "riskier" R&D.

That sets up a triple-whammy, should the company's fortunes take a sharp digger.  Firstly, they're now loaded with debt.  Secondly, if they need to sell stock to raise cash, they're now selling it for a net loss.  Finally (and most ominously), they're left with fewer (or no) new products with which to diversify their offerings.

This is about as antithetical to "agile"/"lean" as it gets.  Being too afraid to take calculated short-term risks sets up more consequential dangers in the long-term.

Tragically, what the post-2008 coddling of the investor class has amply demonstrated is that failure does not have consequences--at least not for those who screwed up.  Anyone who subscribes to the notion of the "rational actor" of neoclassical economics (which I don't) has to admit that its vaunted "rationality" breaks down in the absence of market discipline.

Look.  I have a mortgage.  But my interest rate ticking up at renewal time is preferable to the damage that an artificially-induced recession will do to my income.   Six years (and counting) into the post-bailout malaise, it's amply clear that artificially low interest rates are an anesthetic rather than a cure.   Job growth is anemic at best; wages have remained stagnant.   Worse, any incentive to save against the next recession has been severely dented by those same low interest rates--not to mention what banks siphon off as fees.

But, hey, at least no one's calling it a Depression, right? 

Any sane startup or product manager would have pivoted a looooooong time ago.  Yes, I do realise that the world's largest economies (and companies) don't turn on the proverbial dime.  But, looking at the experience of Iceland post-2008, I have to wonder whether letting banks fail and using the bailout money to write off mortgages wouldn't have been the better option.  Short-term pain vs. long-term gain.  That sort of thing.

Plus, you can't deny the soul-satisfying appeal of Iceland tossing its greedy, irresponsible banksters in jail.  Alas, the only way North America could scrape up enough political will for that would be to turn it into a particularly trashy reality show.  Snap to it, Hollywood! 

A suggestion for lengthening the Provincial purse-string

This afternoon, the Rotary Club and the Chamber of Commerce in Shediac hosted a lunch headlined by New Brunswick Premier Brian Gallant.

Disclaimer #1: I should note that I didn't vote for him in last year's election (because I legally couldn't), and he's so new to the job that I have no idea whether or not I'd regret any vote I might have made.

But I do give him credit for making a fair case for a program that would essentially pay the salary of a young person for the first six months on the job at a qualifying business.

Disclaimer #2:  I wouldn't qualify for the program either as employer or employee, so I don't have a proverbial horse in the race here either.

When I read about the idea, I wrote it off as yet another corporate giveaway.  But after today I'm willing to take a more nuanced view.  If the statistics from other provinces don't have too many asterisks, an ~80% success rate (of keeping the employee working at the same or related field) is more than acceptable.   (Bonus:  Telling those whining about not being able to find ready-made skills or fund the expense of training to put up or shut up would be awesome, IMO.)

As a taxpayer, however, I would hope that there would be penalties for abusing the program.  More importantly, I would insist on an additional and verrrrrrry long string attached to subsidising a half-year of someone's wage.  Namely, that the all data (employee's name excepted) be publicly available on the government's website.

It's not just a matter of accounting to the taxpayers.  The (much) more important public service would be an ongoing record of which employers have a track record of not keeping young employees beyond the six month free ride.  That tells not only potential employees, but also potential vendors which companies are run by people who expect to get something for nothing. 

Please understand that it's not that I think that New Brunswick is rife with that particular species of business owner.  It's just that even one of them can cause serious damage to a small contractor (like myself) or a supplier.  Sadly, this can happen even with signed contracts.  Assuming the aggrieved vendor is able to weather the setback, that cost is ultimately passed on to other, better-mannered clients.  So you'd better believe that checking the public records would be part of my routine due diligence on anyone I'm considering working with. 

Given appropriate penalties for abuse plus public record-keeping, I can, in principle anyway, get behind the proposal.  Because then, not only would it promote business growth, the business intelligence could prevent losses elsewhere in the economy.  Besides, weeding out inefficiencies (in which category I include deadbeats) is what free market capitalism is supposed to be about, riiiiiiiiiight??? 

Frivolous Friday, 2015.02.20: Unsolicited advice to Lenovo

My Gentle Reader and I both realise that history's best, most passive-aggressive form of one-sided "communication" reached its zenith when the 1980s spawned the "open letter."  Granted, once the Intertubes became more or less First-World-Ubiquitous, the open letter--like any luxury-item--became downwardly-mobile.  And thus boring.

But in the original spirit--and on the authority of having been "contractor scum" at a certain company whose initials sometimes stand for "I'm Being Micro-managed" (exceptions made for T.P., M.A., D.P., A.B, and B.W.:  You all know who you are)--here's my advice to the company that took over their PC/laptop product-line.

An Open Letter to Lenovo

It's been a tough week, I know.  Trending Twitter hashtags for two days and counting.  Even Facebook has stopped gawping at the Kardashians and 50 Shades of Domestic Abuse long enough to pay attention.  Bad times.

Bottom Line:  You sold out your users to spammers and left them open to malicious hackers.  All by the cheesy expedient of pre-installing malware and an easy-to-fake root certificate.  I'm sure somebody must have paid you something to go to all the trouble of pimping your (theoretical) customers to spammers.

But, let's face it.  You're not even bush-league when it comes to selling out the people who use your product.  You have to get in line far, far behind Facebook, Google, Twitter, LinkedIn, Instagram, Snapchat, and their ilk for that kind of thing.  I mean, you weren't even bothering to steal passwords, account numbers, or sensitive personal information yourself.  How is anyone supposed to take you seriously?

Your problem is that you're thinking just like a typical I/T company.  Parochial hayseeds!  So narrow-minded, focused on only the eyeballs of the average internet user.  Unlike them, however, you're in a position to monetise so, so much more of your client.  Well, at least until the whole self-driving car thing takes off and then who knows?  That's what should be keeping you up at nightT The possibility of Google having a whole (computing) commuter--or more!--at their mercy.

I tell you, now is the time to execute on your strengths.  You're in hardware:  You can always count on economies of scale.  The future will soon bring haptic keyboards so sensitive you can take fingerprints.  By then, webcams will be capable of emitting low-intensity light.  Either one of those should be worth a fortune when you can sell fingerprints and retina scans by the thousand to identity thieves.

And that's just what current technology could be tweaked to do.  Just imagine the future!  Surely you can (cough!) "partner" (cough!) with the NSA, GCHQ, CSIS, or any sufficiently internetted tin-pot dictatorship to take up the slack for whatever your underfunded, offshored R&D Department won't provide.   For the slight inconvenience of letting them snoop on every twitch your users make, they can reciprocate by opening their books to you.

Think of the possibilities!  Trackpads and touch-screens capable of scanning your customers to the DNA level.  Then it's a mere triviality to wire the button-mouse to deliver a lethal jolt of electricity to young, healthy customers.  Have "sharing economy" contractor already on standby to Uber the corpse to the nearest organ-harvesting facility, and it's like printing money!

And that's just one suggestion for a possible sideline business.  Doubtless, your C-suite has a much more panoramic vision for monetising your users.  Down to the last cell, if possible.  That's why the suits are paid the big bucks, after all.

It's time to pull up your big-kid pants and get to work.  You have a lot of ground to make up before you can go toe-to-toe with the dark-nets or the Russian Mob or anyone else who knows how to use a computer to make money.  Your customers are already paying you a premium for the privilege of being abused--it's time to step up your game.

XOXO,

Doreen

A new unit of measurement

As if the farce of Davos wasn't absurd enough, this week also brings Uber batting its eyelashes at European governments.

First off, Uber's arrogance is breathtaking.  Witness this blurb from CNN's "Money":

"'Uber can share smart data with partner cities to help them manage growth, reduce congestion and greenhouse gas emissions and expand public transportation,' the company said in a blog post as CEO Travis Kalanick unveiled its pitch at a major tech industry conference in Germany."

For a company hailing from the land of urban sprawl to offer any advice on traffic congestion, greenhouse gases, and public transportation to a continent that groks urban density is just beyond absurd--it's surreal. 

I'm gonna go out on a limb here, but I think they're probably ahead of you, Uber.

Pedestrian-only areas in cities.  High-speed rail.  Chunnels.  Mass transit systems carrying tens of thousands of passengers per day decades before San Francisco was patting itself on the back for having a few dozen trolley-cars.  Bicycles as a legitimate form of commuter vehicle...even for heads of state.  Far too many of those concepts are largely sneered at as socialist tree-hugger pipe-dreams from the political center rightward in North American politics.  One has only to look at subsidies and tax breaks to petroleum producers, bailouts to auto manufacturers and contrast with the sorry shoestring state of Amtrak & Via to see where the priorities lie.

But absurdism slides into delusional in Business Insider's version of Uber CEO Kalanick's comments:

"How many unemployed people can come on this platform and find a way to make a living, to be part of an economic opportunity," he said.

If you haven't been following the never-ending controversy that is Uber's dystopian twist on the sharing economy, you've missed how the company's always couched its contractor head-counts in terms of Full Time Equivalent jobs.  My Gentle Reader needn't be shocked to learn that a contractor would have to work well over 40 hours a week to "make a living," as demonstrated by another Business Insider article.  (Original source, plus more lies, d--ned lies, and PR numbers here.)

To quote The Daily Show's Jon Stewart:  "Are you lying to yourself, or are you lying to the people out there?  Because you're lying."

As much as I'd like to place all the blame squarely on corporations and governments disproportionately populated by sociopaths looking out for Number One, we as a culture share some of the blame.

Namely, we've let those folks degrade the word "job" to the point where it includes people working full time, using their own resources, with zero severance/UI, and still having to be subsidised by family and/or state to make ends meet.

Nuh-uh.  If you want to live on ramen as a freelancer while you build up your own business, that's one thing.  But it's high time that we demand that anything that can't support the minimum standard of living and has no safety net for layoffs is not allowed to be called a job.  Period.  Not on the government's job reports.  And certainly not out of the mouths of CEOs like Travis Kalanick.

Thus "job" becomes a very precisely defined unit of economic measurement.  Not unlike when governments stop debasing coinage, the economy is the better for it, because people can trust the standard again.  Check your history books for examples.

But here in the 21st century technocracy, disposable day-labour is not "disrupting" jack-squat.  It's dragging the entire economy back to the Gilded Age robber baron hell of the Industrial Age.  And if I wanted to see that close-up, I'd invent a time machine.  

"Living History"

A coda to last Friday's adventure in home appliance repair:  About an hour later, the repair tech. called back to see whether or not his debugging and repair instructions had panned out.  Which was certainly professional of him.  But before Dennis hung up, the tech. requested his own form of payment for services rendered:  "Oh, if anyone from the office calls, tell them that somebody else told you how to fix it."

Which made the History major in me smile:  Clearly rumours of the guild system's demise have been greatly exaggerated.

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.

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?

Generations

Both my parents spent the majority of their careers working in a hospital environment.   (If you want a good working definition of corporate benevolence, it would be in how my Dad's supervisor said absolutely bupkis about how long it took Dad to return from his maintenance jobs while Mom and I were in the maternity ward and nursery, respectively.  'Nuff said.)

Both parents, however, are at the stage of life where they're more likely to experience hospitals from a customer's, rather than an employee's perspective.  I called Mom today to check in on her progress after surgery a couple months back.  (No, it's not the first time I've called her since then.  Even I'm not such a horrid child as that.)  For the record, she's back out in the yard, shelling walnuts, fully up-to-date on the doings of the wild critters and feral cats, etc.  Business as usual, in other words.

Mom mentioned that the hospital where she'd worked until a couple years back had asked her if she was interested in volunteering.  She said "no."  Which didn't surprise me--she has enough going on right now, even without recuperating from her third surgery in three years.  But then I had an ear-full about everything her former employer has outsourced since she started working there--which, for context, was during the Carter Administration.

Food service, IIRC, was the first to go.  Now housekeeping has been outsourced.  So has billing.  Because, of course, nutrition has nothing to do with health.  And neither does cleanliness.  (My Gentle Reader naturally picked up on the sarcasm there.)  And when, thanks to data-sharing limitations, my Mom is batted like a ping-pong ball between Accounts Receivable and at least two insurance companies when she's still half-whacked-out on painkillers, I'm going to take a dim view of outsourced billing.   [sharpens fingernails] [bares teeth] 

I have a lot of fond memories of visiting that place when I was growing up:  The smell of acetone, the superball-bouncy scrambled eggs in the cafeteria, the stately pace of the elevators, the brain-in-a-jar in the Histology lab (true story).  But I can also understand why Mom turned them down, too.   So far as I can tell, it's still a clean, orderly, almost nurturing place.  But the ghosts of the nuns who built and poured their devotion into it become more transparent with every contractor who slings an ID-card lanyard around their neck.

Fast-forward a generation--meaning me--and press the "zemblanity" button, and there's today's news about IBM selling its semiconductor business to GlobalFoundries.  It's certainly not unprecedented, given IBM's sell-off of its PC/laptop business to Lenovo a few years back and some of its server business earlier this year.  Except that this isn't your typical offshoring:

GlobalFoundries will take over IBM manufacturing facilities in New York and Vermont, and the company "plans to provide employment opportunities for substantially all IBM employees at the two facilities who are part of the transferred businesses, except for a team of semiconductor server group employees who will remain with IBM."

Thus, at least in the near term, GlobalFoundries will employ IBM expats at IBM facilities to make a profit at what, for IBM, was a money-pit.  And IBM's taking a sesqui-billion-dollar hit on the deal besides.   Slow-clap for IBM management there.  (Sarcasm again, btw.)

Granted, I haven't seen the inside of the Blue Zoo since Lou Gerstner was yanking the platinum ripcord on his golden parachute.  And, even then, being "contractor scum" insulated me from the insane (unpaid) overtime and pension-jigging and attrition-by-early-retirement and other assorted idiocies inflicted by the buscuit-salesman.  But my frustration really boils down to one similar to Mom's.  Namely, that the definition of "core competence" has become dangerously strict.

Now, I'm certainly not arguing in favour of vertical monopolies.  The fact that Monsanto is allowed to GMO a seed specifically optimised for the petro-chemical atrocities they market frankly blows my mind.  As Bruce Sterling put it, "Teddy Roosevelt would jump down off Mount Rushmore and kick our ass from hell to breakfast for tolerating a situation like this."  And he's absolutely right--even when he was talking about software monopolies.

Maybe I've just been out of the server space for too long.  For all I know, pushing mission-critical data off-site to cloud servers doesn't give CIOs the willies it would have given them a decade ago.  Maybe Microsoft has finally earned enough enterprise-computing street-cred to muscle out the Big Iron in the server-room.

But I do know that outsourcing always entails friction and a certain amount of bridge-burning.  In the case of Mom's ex-employer, it's orders of magnitude easier and less expensive to retrain (or, if necessary, fire) a under-performing employee than it is to cancel a contract and find a replacement when work isn't up to snuff.  When you're a technology company that's weathered two decades of commodisation in both hardware and software by optimising one for the other, throwing away that balance makes no strategic to me.

When I look at the risk of things IBM flags as higher-margin (cloud, data and analytics, security, social and mobile), there is not one of them that I would flag as being "owned" by Big Blue.  (Cloud?  Amazon.  Data?  Oracle, with Microsoft hot on their heels.  Analytics?  Everybody's a "big data" guru these days.  Security?  Nope.  Social?  Please...who isn't gunning for Facebook?  Mobile?  Are we seriously expecting for an IBM phone?)

I owe IBM credit for making me a decent technical writer and for teaching me basic white-collar survival skills.  Oh, and for disabusing me of the notion that working inside the belly of the leviathon is securer than working outside it.  But apart from my comrades and the cafeteria/coffee-shop/cleaning ladies, there's no love lost for the big blue behemoth on my end.

Yet it galls me to see a company that lionised its R&D department (and the patent lawyers who filed every brain-wave thereof) hitching their wagons to other people's horses.  Or, perhaps more aptly,  jumping onto other bandwagons.  Because bandwagon-passengers forfeit their right to drive, right?

Mirror, mirror

Normally, I'm skeptical of the argument that government should be run like a business.   First and foremost, businesses are intended to make a profit, and anyone who's ever walked past the Chapters "History" section should know that has never been compatible with good government.  (I mean, does anyone seriously want tax collectors working on commission like they did in the Bad Old Days?)

Nevertheless, management principles remain largely the same, regardless of whether the proverbial cats being herded are public- or private-sector.

But let's back up a bit for the benefit of some of my Gentle Readers who reside south of the U.S.-Canadian border.   Because Canadian party politics tends to follow a more European model than an American one.  In the U.S., of course, it's possible that the President or the Governor of a State may belong to the Coke party while both houses of the Legislative branch are predominantly Pepsi.  In Ottawa and the Provincial seats, however, the Prime Minister and the Premiers are the heads of the winning parties in the national or provincial jurisdiction, respectively.

Certainly, the arrangement spares the Canadian electorate the unedifying Legislative vs. Executive spit-balling which the American public has come to expect from its "leaders."  But it does have the unfortunate side effect that the party in power has a worse-than-usual tendency to act as if it "owns" the government.  That extends to the executive ("deputy minister") jobs that are filled by appointment.

Sure, that sort of thing happens in the U.S. too.  The difference is that the holder of such a job in the U.S. is expected to find her/his own golden parachute, often in the form of a cushy job on Wall Street, K-Street, with a (cough!) "think"-tank, or as a senior law partner.  Not in these parts, where the payout is straight cash when another party wins the latest election (and wants that earmarked paycheque to reward one of own its supporters...who weren't themselves elected this time).

Naked cronyism certainly can't help morale in the trenches, even at the best of times.  Certainly not at a time of downsizing (via attrition and layoffs) in the public service.  But that's not the only, or even the worse, blight on the profession.  A culture of sycophancy, not surprisingly, is another.  (Canada's notoriously muzzled scientists are shining exceptions.  Ditto the Parliamentary Budget Office.)

And that boils down to one of the Deadliest of Deadly Sins in Management--namely, the sin hiring those like yourself.  (Or, far worse, people who could almost be you...if only they had your talent, charisma, work ethic, savvy, or whatever you think is your special sauce.)

Contrast that with Barbara Corcoran's delicious (if slightly NSFW) story of how she found her business partner.  (Note:  Scroll to the bottom of the page and click the "PEOPLE: Expanders or Containers" one.)  The salient point is that no one has the personality traits optimised for everything that needs to be done.  (You know, Tony Stark and Pepper Potts.  That sort of thing.)  And, too, the bigger the organisation, the bigger that "everything" becomes, amirite?

You hiring a lesser you (who in turn has the power to hire lesser thems) is no different, really, from holding a mirror to a mirror:  Each reflection of you is smaller.  And while it's a fun exercise...once...when you're six...it's no game for adults in the real world.  Much less managers or leaders.