Half-glassing it

Executive overview for folks who don't work in software:  There's a stage in an application's life known as the "Beta."  It has nothing to do with fish--not enough "T"s, for starters.  Basically, it means that the developers--or at least their managers--think that the code is reliable and useful enough to let outsiders look at it.  "Beta" used to come in two flavours:

• Limited Beta, wherein hand-picked outsiders were allowed access to the application.  (Read:  Friends/relatives/ex-coworkers were nagged into taking it out for a drive.)
• Open Beta, wherein any interested party had access to the app. with no guarantees that it wouldn't crash their computers and/or eat their pets.  (Yay, Slashdotters!)

In later years, hybrids of those models have evolved.  Remember when you revived your high school sucking-up-to-the-cool-kids skills to score a GMail/Ello invitation?  Yeah, that's one of those hybrids.

Anyhoo.  I'm the developer for an app. scheduled to go into an invitation-only Beta phase within a few weeks.  I'm stiffening my spine by re-reading Eric Ries's The Lean Startup for, like, the 2nd or 3rd time (I forget which).  Because, by my usual standards, the code (and infrastructure) quite honestly suck.  But by "lean" startup standards, that's absolutely OK.  In fact, it's considered optimal.

The "lean" methodology takes its cue from the "lean" manufacturing processes that were all the rage a couple decades ago.  And while my view of management-by-fad is not significantly different from my view of kings and queens of centuries past (or not so past) who kept pet astrologers, "lean" management at least admits that it's a calculated--yea, even disciplined--response to certain types of uncertainty.

According to "lean" doctrine, the holy grail of the startup is the "MVP," or "Minimum Viable Product."  Interestingly, MVPs can originate from established companies (that haven't ossified to the point of knowing nothing beyond milking the existing product-line or desperately scrabbling for a hold on the trailer-hitch of the the latest-greatest bandwagon).  The central idea is that you focus your efforts on the single thing that scratches an itch no one else has been able to reach...at least for your target demographic.  Sure, not everyone itches in the same place--heck, some folks really only need a vigorous massage, when it comes right down to it.  But the early adopters will give you the revenue and insights you need to go mainstream.

The problem is that MVPs are UGH-lee.  Features that should be no-brainers are missing.  And features are vastly outnumbered by bugs.  Performance is slow...assuming the whole thing doesn't crash altogether.  Error-logging is practically non-existent.   Cut corners and hard-coded "special cases" are the norm rather than the exception.  Customisation?  That's done by directly editing the database.  And automated build-processes?  Puh-leeze--getting a new version out the door would make Rube Goldberg weep tears of blood.

That's excruciating to the software developers who have to hold their noses, grit their teeth, and shove the dewy-eyed Beta version out into the cold, cruel world.  There's no post-release euphoria, because the pre-release sprint is merely the warm-up for the iron-keyboard marathon of whack-a-mole bug-fixing and the unholy offspring of Tetris and Calvinball that determines the next set of features.

Example:  One of the enthusiastic early adopters wants this one extra feature that will put them eighteen months ahead of their closest competition.  And--get this!--they're willing to pay for it.  Woo-hoo!  Problem is, their pet feature so whacked-out that it will change the overall architecture of the app.  Worse, absolutely no one else has asked for anything close to this.  Ever.  So...do you shut up and take their money?  Or do you focus your already-overstretched resources on making the app. more appealing to the mainstream?  That sort of thing.  Fun times.  And just another day in Beta-land.  Ah, the sexy glamour of software development...

But subjecting my code (yet again) to the rigours of the Real World(TM) makes me realise that, at some point in its life, code exists in a quantum state.  There's the optimism (i.e. glass half full) that it will be "good enough" to add value for its early adopters...and have enough time/resources to evolve for a wider ecosystem.  There's also the cringing awareness (i.e. glass half empty) of just how much duct tape tenuously holds together too few features...that all have your name (and reputation) on them.

Typically, that "quantum" state isn't long-lived.  Which is a mercy, because it's rather uncomfortable.  If I were Schroedinger's cat, I'd be gnawing my way out of the box by now.