Wednesday, November 26, 2014

The flip-side of an old engineering adage

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

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

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

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

"Done" is the enemy of "better."

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

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

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

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

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

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