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.