Scott Hanselman’s recent post, on a week of annoyances caused by troublesome software, was entertaining because we’ve all been there. Thankfully it managed not to indulge (or at least I could stomach) the allusions to a lack of “passion” and “craft” and the comments were mostly sane, albeit I didn’t necessarily agree. I must confess to occasional astonishment at how much does work, not only in the world of IT but the world in general; yet we can do better, and if we didn’t think so then what’s the point?
release early, release often”. For example, I like Agile - since customer requirements will evolve it’s helpful to have an adaptive method that anticipates this - but it comes with an understanding that what’s initially released isn’t the finished article. Ironically the separation of concerns afforded by such patterns as MVC and MVVM not only enable this, but necessarily come with additional code you’d expect with any abstraction.
One can argue the difference between internal and external releases, and there is a balance, but if we don’t release early then any perceived advantage from user feedback becomes moot. The point here is that “less than perfect” is something we accept, as quicker and better is expected in the long term. The business challenge is to ensure as much effort is extended to the updates as the early release - which in turn requires challenging (or should that be refining?) an “if it ain’t broke” mentality.
A further confession: I’m not particularly understanding when “less than perfect” hits me; though yesterday’s example was a bug. In creating an online account to manage my Barclays mobile phone insurance I discovered the password format validation was different to that on logging in; the latter was strictly alphanumeric, the former allowed for what would have been more secure. Thus the telephone call I’d hoped to avoid by creating said account became inevitable; not that I could explain the problem to the person on the other end.