The Recursive ISV

Recently on the BOS forum there was a discussion about some of the weird things people do in relation to various software packages and specifically using spreadsheets like Excel ™ as databases.  I’ve had my own experiences with users in office environments using Excel ™ for this purpose and them getting into a real pickle.  I’ve even had to correct some IT trainers for *teaching* that Excel makes a great database and is “no different, but easier to use than Access ™” and other database systems (where do these guys and gals get accredited?!!). 

But the post that took the cake, in terms of things people do, was submitted by Patrick McKenzie.  Patrick had met people embedding OLE documents into OLE documents into OLE documents into…   You get the picture.  The classic mirror facing a mirror paradox. 

If Alfred Hitchcock had been a computer programmer he would have taken glee in implementing this *everywhere*.   Thankfully he stuck to making movies about mirrors facing mirrors. 

So would Microsoft’s dev’s have ever considered that users would do this OLE inside OLE ad infinitum routine?  I can’t answer that.  I do know it gave me a long chuckle when I read it.  But it made me think, just because we *can* allow a user to do such a thing, and given how messy it can get (and dangerous to data) and of course the average computer users’ proclivity in doing something the developer never dreamed of, should we allow such things to happen? 

If indeed we can justify it happening in certain instances, should we not at least warn them of the potential of such techniques when they start to do it in such a manner?

IMHO. Yes!  

I believe this relates to ISV”s and mISV’s as well.  A lot of programmers (I think most of us have been guilty of this at one time or another) introduce features because “we can” rather than because “we should”. 

Having done it we don’t safe guard the user from (with the benefit of hindsight aside) obvious abuse of the feature.  We are then left with a conundrum when the feature is abused as the user blames the programmer for allowing whatever went wrong to go wrong – even if it’s due to abuse in a manner never envisioned by the designer of the feature (or coder of the feature if they are distinct persons).

We are left with two choices in this instance.  Pull the feature and cop the wrath of those who love it and *need it* or try and bug fix it so that it handles the whole problem gracefully. 

But there is, to my mind, a third option.  It’s done before the user ever becomes aware of the feature, before they even see or hear of it.  It’s incredibly easy to implement and is 100% guaranteed to be bug free and user error free.  It’s simply this:  Do you really need that darn feature in the first place or are you adding it because “you can” rather than because “you should”?  

If the answer to this is “because you can” then the feature is going to bite you, potentially later, in many instances.

I use a lot of pro audio software.  One of the big “features” these packages have is the ability to use plug-ins based on Steinberg’s VST ™ API.  This API is pretty cool, it’s got a massive market acceptance and third party support and is *the standard*.  But…  It’s a right royal pain to work with when you need more than one audio effect open at once, even if you have multiple monitors. 

But that’s not the worst part (and it’s true one can live with this).  The worst part is the attempt to model the UI of these plug-ins on real world user interfaces.  In this instance knobs.  Round knobs are cludgy and hard to use via a mouse (or even fingers on a touch screen).  Yet they are thrown in by the developers of these plug-ins time and time again, just because *they can*.  Practically a slider control – not dissimilar to the linear fader style control in the “real world” - is far easier to manipulate with a mouse.  In fact in the real world they are used on pro audio devices for *exactly that reason* - they are easier to use and more accurate even with fingers.  In a domain where minute changes to a signal can create the next “Itchycoo Park” this is simply to vital to mess up with a cludgy knob.

OK.  We could use the keyboard to do it – right?  Sure, but now we’re into the fix a feature to force it to fit territory or the “mirror within mirror” syndrome of OLE embedding discussed above.  I’m a great believer in cool interfaces and firmly believe cool sells.  But there is cool and useless and round knobs on a computer interface are not cool – they are a bloody nuisance!

For the sanity of your users and your own sanity when it comes to fixing it – ask yourself more than once if a feature is *really needed* before you throw it in because “you can”. 

Consider it from all angles and consider the potential for misuse.  It might just save you and your customers some heartache later on.