Just as playing a musical instrument or singing musically is far more important than playing or singing accurately (indeed, a friend of mine sings the right notes only rarely, and most of those accidentally, but his musicality is profound – imagine a male version of Florence Foster Jenkins), and just as a good consultant needn’t know anything about anything in particular (it’s more important that he or she should look smart, ask good questions and listen well, than spout dry technical truths), and just as sales is more about being liked than knowing something about what you’re selling, and just as speaking eloquently is more important for a politician than having anything useful to say, so what software actually does is far less important than how it looks.
Well, perhaps I exaggerate, but there’s an iota of truth in some of this nonsense and I’ve reluctantly accepted the view that what’s called the ‘functionality’ of software (how I hate that word, but continue to use it) is by no means the only thing that matters.
I design a configurable software system called time@work. It’s designed for Professional Services Organisation such as lawyers, engineers, and consultants, indeed any organisation that needs to record the time and expense incurred on projects. We have nearly 300 customers around the world, and we meet our customers requirements without needing to change the underlying software code – we click and build and configure the basic software to do millions of different things.
Of course, we bring out new versions from time to time, and most of the changes we make are inspired by our customers’ needs. We add new options and checkboxes and functions, and I doubt that we or our clients will ever run out of such ideas, but we keep fast to the rule that we’ll only have one version that’s ever more capable. I was once a programmer (and yes, once a programmer, always a programmer (it’s like being a Roman Catholic, I believe)), and it has often seemed to me that adding more ‘functionality’, ever greater capability, is more important than anything else. More important, for example, than that the system should look attractive.
But of course I’m wrong about that, though less wrong than I used to be, and I have to remind myself from time to time of that old adage in the business software implementation that projects fail more often for other reasons than that the software doesn’t do exactly the right thing.
That doesn’t mean that you can use Microsoft Word as a manufacturing requirements planning system, or Microsoft Excel as an airline booking system, but there’s a grain of truth in the idea. Configurable software such as ours, however brilliantly conceived (!), doesn’t always do exactly what customers want, and there must always be flexibility and imagination and compromise on all sides if an implementation project is to succeed. You can concentrate on nothing else but ‘functionality’ and you’ll never produce an infinitely capable system. A year of software development work might take you from a 94% fit to a 94.5% fit.
The problem is that if you concentrate only on capability, you’ll neglect those things that sometimes seem more trivial to you if you’re a programmer – the graphical look and the ‘usability’ of the system. If there was a road to Damascus for me, it was in the development of our iPhone App. Developing the systems@work App was a great lesson. The world of Apps is unforgiving and to succeed you must meet higher standards of attractiveness and usability than in the kind of software that’s used in the dark corners of accounting departments.
And so, in the recent version of systems@work’s time@work, expense@work and forms@work we’ve spent time and money on making the software look a lot nicer and easier to use. I don’t regret it. We released Version 6 a few weeks ago and it’s been received with enthusiasm by customers and resellers alike, and I, too, find it a greater pleasure to use.
This took months!
There’s still more to do. Weeks of programming time can be consumed in making paging controls and field lookups look consistent across the system, but we’ll continue. That’s not to say that checkboxes here and there that add to the capability of the system will be entirely neglected, but for a few weeks ‘functionality’ must take a back seat.
The matrix, above, shows data for another division, one which executes more fixed price projects. It’s clear that decisions about the write down or write up of time are made sometimes many months after time is recorded, and as year-end approaches large values are written off. This is less virtuous.
Adam Bager 