When I logged in to my bank's online system to pay some bills last night, I was greeted with the following message: "Bill payment system upgrade completed."
Uh-oh. That's a message I don't want to see.
...
The old system would queue up payments from multiple accounts in a single screen. The new system, with "simpler navigation that makes paying bills easier," won't let me do that. Now I have to make payments from my household account in one batch, and from my business account in another. The forklift upgrade didn't just temporarily disrupt my online banking experience, it permanently subtracted value from it.
...
The central tenet of modern test-driven development is continuous improvement by steady accretion of small, incremental changes, with continuous evaluation of the effects of each change. This model should apply not only to the unit-testing of modules of code but also to the field-testing of aspects of user interaction.
Businesses born of the Web, such as Amazon and Google, have always known that it's now possible to evolve systems in this fluid way, and they've always made the most of the opportunity. Many businesses that predate the Web, though, still cling to anachronistic methods dictated by constraints that no longer apply. It's not a winning strategy. [Full story at InfoWorld.com]
If you're a local business in my town, it sucks to have me as a customer. Consider my bank, for example. Every time they upgrade their online bill payment system, I write a column about it. Last time I whined about having to re-enter all my payees when they switched providers. This time I bitched about an upgrade that scrambled my expectations and neglected to carry forward a useful feature.
In another column about securing the analog hole I complained about information leaks at the hospital and the YMCA. The Y's sin, you may recall, was a new barcode authenticator that left personal information sitting on a screen, visible to everyone entering the building.
I'd rather praise than criticize, so I'm happy to report that the Y has corrected the problem. As of last week, there's a privacy hood shielding that screen. Problem solved!
Update: Marc Thornsbury writes:
It probably wasn't your intention, but you managed to point out one of the glaring problems with applications delivered as services by third parties over the web (call is SOA, ASP, what-have-you). While the trade press has been all over this like a cheap suit for several years now, it just refuses to take off (lo these many years and Salesforce.com is still the only substantial success story).Excellent point. I would only note that forced upgrade is not a /necessary/ consequence of SOA/ASP. Service providers could, and in my view should, continue to offer prior versions of services for quite a while, and enable service consumers to upgrade on their own schedule.
And you've managed to bring out, in stark relief, one of the reasons it hasn't. When it comes down to brass tacks, lots of folks (like me) don't want to play the unwilling victim to someone else's decision as to whether an interface is acceptable or not, or software is no longer "beta". I never like to run x.0 of anything. But when you've turned your software over to someone else, *they* make that decision...not you. There's no "opt-out" option. If you were running your own bank client, you could have opted to skip the "new version" and waiting until the kinks were worked out in the next one (or perhaps give yourself time to learn the new interface at your leisure before making the switch).
There are many circumstances where functions ancillary to your operation can be moved outside and changes to them have minimal impact. But where an app. has high/broad use or addresses a core function of the business, the arbitrary decision of someone else can bring your production to a near standstill and overload your help desk...and generally without warning. Who wants that?
Former URL: http://weblog.infoworld.com/udell/2006/06/01.html#a1459