Was Perfect Once

From Ben Hammersley’s book “Now for Then – How to face the digital future without fear, Part 60. Failing Gracefully, or Why Everything is Beta Now”

“On-line everything is beta because the state of perfection is permanently receding on endless waves of innovation. And an app that is adaptable, or that can deliver a soft landing even when it fails, is far more valuable than the perfect-for-a-moment app that either lacks the flexibility to cope with whatever is coming down the line next, or is too late. Good-Enough Right Now beats Very-Good Later, and completely defeats Was Perfect Once.”

In my innocence the above description was far closer to the type of development cycle I was using when doing my IT stuff than the official line at Process Control or GIS. Both (but especially the latter) were so glacially slow that by the time a solution was ready, quite often the problem had changed substantially. Also, their approach seemed to assume that the developer had all the information available to build the finished article, which from personal experience I found was hardly ever the case. Especially since only a selected few users were consulted when compiling the needs analysis.

In the end, what you receive from such an approach is something that may look snazzy and may have a wow factor on day one, but soon the user starts to feel the limitation of usability when it becomes clear that getting new requirements added means a complete new turn of the development cycle – which most users feel (in my view quite rightly so) should have been an automatic extension of the initial development cycle.

What I’ve found from personal experience is that, even if the user has a full say over the initial requirements list, initial use of the system will either show up gaps in the initial understanding of the customer’s needs, or create further requirements based on an extension of the initial design. And that is just assuming that all relevant stakeholders have been able to have their input, which is not always the case.

The answer: build a continually developing system where interaction of the user and the system grows asymptotically to something that approaches stability – that is, until outside factors induce the next step change.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s