Chasms and bridges

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


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

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

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

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

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

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

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

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

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

Seems like a contradiction, no?

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

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

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

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

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

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

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

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

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

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

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

(Hint:  Nope.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Frivolous Friday, 2016.04.01: Wishful, Wistful Thinking

We code-crunching types tend to think of ourselves as logical and data-oriented, but we're not above pipe-dreams of our own.

Understand that the last few workdays have seen a significant up-tick in traffic between my development stations and the server.  Alas, my younger, newer, PC with the snazzier OS is the one with the wifi hiccups.  (The 2nd-hand Dell from 2009 shambling along with Debian?  Rock solid.  Nat'cherly.  Get off my lawn, you snot-nose Ubuntu kids! ;~P)

Anyhoo.  As I babysit the second third fourth database restore of the day, I can look at a single complete stored procedure (and the start of a second one) that represents the sum total of today's "work" that hasn't involved email.  :~(  And I again internalise the problem with such intermittent bursts of down-time.  Namely, how they're good for housekeeping (e.g. backups or quick web searches in response to events like this week's Build2016 announcements), but not heads-down work. 

And (mentally) sandwiched between all today's nickel-and-dime penny-ante (yeah, I just mixed monetary metaphors--roll with it) is sugar-plum fancies of the (mature) software developer.

In my favourite fairy tale, the record-locking gremlin (or something equally time-wasting) has struck again, the coffee thermos is both empty and cold, and our heroine knows better than to make another pot at this point in the day.  And just as her shoulders droop in despair at the lateness of the clock and the shortness of her list of crossed-off tasks, The Programming Fairy Godmother appears.

The Programming Fairy Godmother (or, "PFG," as we'll call her from here on out) is dressed in a white silk ball-gown + tiara, both deliberately reminiscent of Ada Lovelace--though sporting horn-rimmed glasses like Admiral Grace Hopper.  (Hipster!).  In lieu of a wand, she carries a shining tablet computer (because tablets can do everything, amirite?)

"Despair not, my dear," she says.  "In all your career, you have faithfully treaded that fine line between over-engineering and creating technical debt.  You have sanitised your inputs.  You have, despite their appalling lack of appreciation for data integrity, maintaining empathy for the end-user.  Moreover, you have commented your code, unit-tested, spot-checked, made frequent source-control check-ins, and generally shipped on time.  For this you have earned a reward."

"Huh?" says our heroine.  "Uh, that's just doing my job.  You know, like a real programmer."

"Oh, honey, you have nooooooooooo idea..." replies the PFG, with a near-audible eye-roll.  "If you only knew what can bag you six figures plus stock options in Silicon Valley..."

"Good point," replies the programmer, "let's not go there."

The PFG holds up the tablet, which begins to play a PowerPoint retrospective of the programmer's career.  There she is as a much-younger student, waiting in line waiting for the printout of her program and output on fan-fold green-bar paper.   And regularly sneakernetting--as big floppy discs give way to smaller floppy discs, and then to CDs, and DVDs and flash drives, and occasionally, backup tapes.  Somewhere along the line, punctuated by the "RRRRRRRRRR--broingity-broing-broing!" of a modem, memories of sneaker-netting were interspersed with waiting for web pages to download.  Also, FTP, SFTP, SCP.  Backups.  Restores.  And, regardless of decade or operating system, our heroine can be seen twiddling her thumbs while her computer boots up.  Reboots to install the updates to the Adobe software updater--'nuff said.

If her fairy godmother had meant the presentation to be uplifting, she had failed miserably.  The programmer felt the weight of all the, well, waiting.  Minutes, hours, and (effectively) whole days of not being able to just tuck into the work at hand with her full attention--all flashed before her in a varied, yet monotonous panoply of wasted time.  

Being an Upper Midwesterner only recently relocated to Canada, the programmer bit back her disappointment and considered the possibility that she was being trolled by a supernatural being.  "Well, it's good to know that someone still appreciates the virtue of patience," she ventured once the excruciatingly soporific mini-biography had concluded.

The Programmer Fairy Godmother gave the programmer a blank stare.  "You're seriously kidding me, right?  No, kiddo.  I'm giving you that time back."

"Wuuuuuuut?" was the best retort our stunned heroine could muster.

"You heard me," said the PFG.   From the standpoint of your cubicle, time stands still until you fill all that otherwise wasted time.  Now get off that mocha-latté-padded butt and build something awesome.

So, with scarcely more than a "Thank you!" hollered over her shoulder, the programmer immediately scarpered the heck off.  Because her Momma might have raised a lazy, selfish git--but she for sure did not raise a fool.  And, despite wasting a, frankly, inexcusable amount of time screwing off on the internet, the programmer managed to manage her time well enough to build A Thing.  With (for a change) herself and her friends, and (incidentally) some of the rest of humanity in mind, thank you very much. 

When all was said and done, code just plain shipped.  Without answering to the mandarins of Marketing or Legal at every turn.  Without enduring infinite fractal Groundhogs Day-esque strategy meetings.  Without quashing the eternal food-fights over flat vs. skeuomorphic design.  (Or, worse, Helvetica vs. Suisse fonts.)  Without having to look over her shoulder for hockey-stick inflection-points in the adoption curve.

And, after a couple of iterations (and the inevitable hiccups), everyone involved was appreciably better off for the results, thank you.

Mind you, the programmer was never wined & dined by Y-Combinator or Andreeson-Horowitz.   She didn't publish self-congratulatory business self-help woo, much find herself on the TED/SXSWi circuit.   She never once did a reddit AMA or made the cover of Inc. or FastCompany...though she may have been interviewed by an intern for TechCrunch.  Or maybe it was CNet.  She can't remember now, but honestly it doesn't even matter--that piece never saw the light of day in any case.

But I think that we can safely say that this programmer, at least, lived happily ever after. 

The Accidental Internship

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

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

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

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

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

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

That was last Tuesday night.

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

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

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

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

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

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

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.

Frivolous Friday, 2016.03.04: "darwin.config"

When Empathy > Technology

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

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

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

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

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

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

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

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

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

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

Exceptional madness

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

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

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

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

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

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.  :~/

Trading the creeper for the stalker

I'm on the "admin." email list for a volunteer group that organises monthly tech. talks.  I'm not the volunteer who orders the pizza, so normally I don't fuss too much over how many registrations have landed.  But I recruited this month's speaker, and wanted to give him a rough head-count (especially since it was a higher than usual, which is always good to report).

One downside to flipping through all those EventBrite notifications, however, was the huuuuuuge and depressing preponderance of "anonymous" email accounts used to register for the talk.  Clearly, someone--well, pretty much everyone in our almost-big-enough-to-be-statistically-valid sample--has had their workaday email address trammeled by someone before.  And (more to the point) that's not news or even remarkable.  It's merely evolution in action, really.  In the sense that arms races can be considered "evolutionary," anyway.

Until now, I'd failed to see the extra irony in that response.  GMail and Hotmail (and the odd Yahoo) accounts are, of course, a prophylactic against having one's attention-stream repeatedly crashed by spammers and scammers.  Not unlike how single women will wear fake wedding/engagement rings as a prophylactic against being creeped-on.  (Needless to say, its deterrent effect is never 100%, but on balance it's worth the clunky el-cheapo jewelry.  Pro tip, ladies:  A layer of clear nail polish over the metal of a dime-store ring will extend its lifespan by months.  Trust me on this.)

So, in an attempt to preserve the online equivalent of personal space, people choose to trade their privacy and a certain amount of attention-span.  Because of course Google, Microsoft, and Yahoo are monetising both.  Behind the scenes, naturally.  Which apparently makes all the difference.  It's difference between the creeper at the pub who won't take "go away" for an answer and the stalker who rifles through your garbage and eavesdrops at your window.  But the latter is at least discreet about it--incredibly polite, in fact--and (best of all) you're not its only target.  So it's not even personal, which almost makes it not-creepy, hey?

Please understand that I'm actually not slagging Google or Microsoft or Yahoo here.  Blocking all the spam and worse spawned in the underbelly of the internet is itself an arms-race.  Just handling the sheer amount of illicit email traffic chews up resources that your average I/T department can't afford.  Bayesian filters require constant "training" and updates to the code to keep up with the latest scams, viruses, and desperately incompetent marketing hacks.  Only huge corporations have the resources to A.) Scale up to the challenges, and B.) Pay for it all with targeted advertising revenue.  "Targeted," naturally, implies sniffing email for keywords and (more importantly) patterns and embedding compatible ads in the user experience.

Within the confines of the free market, we're left with an imperfect system.  In essence, we're allowing the stalkers to protect us from (most of) the creepers.  To imagine any other outcome is reading History backward without remembering that it is lived forward.  And also to forget that people people--perhaps as much as the corporate people of which Mitt Romney famously spoke--have zero conscience when it comes to externalising costs for things you can't actually touch.  Maybe even negative conscience, given some of the rationalisations I've heard.  Internet security, naturally, ranks high on that list.  Which is precisely what criminals and griefers are banking on.  And, as if we could forget, Marketing's sins are both legion and legendary--regardless of medium.

If it weren't for those inconvenient truths, I'd feel less futile in wishing for a do-over on email at this late date.  Namely, a do-over that doesn't require the ghetto-isation of personal email.  Because a tool that's so critical to modern life (on the clock and off) doesn't fit well into any of those flows on or off the clock.  To say that I'm fussy about my tools (in software development as well as elsewhere) is a massive understatement.  You take care of your tools, and they'll take care of you.  I believe that.

Predictions of email's demise are over a decade old.  (Just like predictions of the demise of many things.  Particularly when made by people too busy penning tech. articles to read any Geoffrey Moore.)  But let's imagine that the street-corner nut-job with the doomsday sign is correct and that The End is, in fact, Near.  That would be our last, best hope for owning up to how much #FAIL is baked into the current system and keeping it out of the Next Big Next Big Thing, yes?  Effectively, means that it's time to (finally!) put a price-the on "free" email that reflects all its costs:  The internalised costs of our own context-switching as well as externalised costs of subsidising crime, giving viruses a vector for spreading, etc.

When the internet first went mainstream, we were treated to starry-eyed predictions of democratisation and broadened horizons and geysers of previously untapped human potential.  To some extent that's happened...along with other things less laudable or savoury.  But there's no excuse for not learning the lessons of the past two decades, and far less excuse for perpetuating its sins.  I'm at an age where I don't have soaring hopes for the future--after that whole flying cars and Mars vacations thing didn't pan out and all.  But I'm all-in for "not-creepy internet"  Can we get it right next time?

"Day Two"

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

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

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

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

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

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

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

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

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

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

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

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

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

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