Last Friday, I got an opportunity to use a piece of enterprise software that has a monopoly on a particular public service sector here in the UK. From my initial research about the product, I’d been expecting something that generally was pretty decent, but was a pain for system administrators to perform maintenance on (as all maintenance had to be done on-site by trained engineers): the frequent reports of crashes and days of down-time, I’d put down to poor system management. This particular system, which for a variety of reasons shall remain nameless, has to be one of the most confusing I’ve used to date.
The first facet of this poor design was the UI. When talking of a crowded and largely ‘unusable’ interface, Word’s classic use of toolbars are often cited as an example:
Obviously, this is a bit of a misnomer, given the ability to hide/show relevant toolbars at relevant times, but the point still remains: a crowded interface is not desirable in the slightest. But when getting my hands on this system for the very first time, it became clear that this over-crowded nature was inherent in every part of this enterprise system. Wherever you looked, labels overlaid text boxes, text fields were positioned off-screen, with no way to scroll to them, text sizes were erratic to cram in as many form fields on one page as possible and standard UI conventions (such as button hover effects, etc.) had been replaced by inconsistent alternatives.
For years I’ve wondered how it was that so many government systems failed, and further puzzled at the regularity with which said systems completely lost data and were, inevitably, decommissioned – but no longer. The chance for three hours with this government-endorsed system answered a lot of questions. It’s become clear to me that the primary failure in systems like this is poor design from the outset. Sure, even the best-designed system fails at some point, and every enterprise system is put under huge stress and strain that could lead to downtime, eventually… but many are simply plagued with underlying flaws that should have been ironed out in the design phase.
The system in question, though, is a maze of menus, features that overlap, crowded data outputs and show-stopper bugs. Basic design principles, such as retaining the ability to tab through form fields have been completely left out, and standard system shortcuts are abused and repurposed. 90% of the program’s features are not available within 8-10 mouse clicks, and even the regular users of the system seem to just randomly click poorly-labelled buttons and scroll through lengthy list-based screens until they find what they need. The data input forms are all but abandoned in favour of importing Excel spreadsheets for each entry (apparently using the spreadsheets and the program’s import function is far, far quicker than attempting to enter the data in the system itself) and the system lacks a reliable reporting interface. Validation is nowhere to be seen, and coming across text in the phone number field, and the like, is the norm.
But if the user interactions and the UI weren’t bad enough, the underlying system is, quite simply, a dog. A simple task such as searching a table of 500 rows on a particular, simple, condition such as “WHERE gender=’F'” took nearly 30 seconds to report, with no indication of the progress of the task given. Completely devoid of the idea of threading, the program enters a ‘Not Responding’ state every time a simple task is requested of it, and crashes when the data inputs are outside of expected ranges. I’ll admit that Microsoft SQL Server isn’t my favourite SQL deployment platform (for a variety of non-performance-related reasons), but no system should perform this poorly, unless it has major underlying flaws.
Using this system reminded me of a case study I undertook back in University about the London Ambulance Service’s attempts at a computerised dispatch system in the early ’90s: the project was given to the lowest bidder (who bid over £700,000 less for the project than any other bidder); came in massively over-budget; failed completely during it’s first deployment; had major interfacing bugs with the purpose-designed hardware; resulted in the death of twenty people whose calls were either not routed in the system correctly or were disconnected; ‘lost’ ambulances from its tracking software at the rate of several per hour; and was ultimately scrapped less than 24 hours after it had been initially deployed.
‘Fundamentally flawed’ is the only way in which I can describe the system I had the privilege misfortune of using last Friday, and I’m very glad that it’s not responsible for a safety-critical area of our public service sector!
It’s no wonder that so much data has been lost by government organisations when even the most simple data protection controls and security measures are completely absent in many existing enterprise and government systems. And if that’s not bad enough, consider the number of extra hours public workers need to be paid, on the tax-payer’s dime, just to navigate the poor and unreliable user interfaces that are haphazardly plastered on top of flawed system architecture.
The fact that so-called ‘professional’ software developers get away with systems like this is laughable. And, I suppose, sometimes you have to laugh… or you’d cry.
