Committed to Users not to Committees

If you’d been asked to name the 100 most important things or rather 100 senseless things - what would you start with? Right, there are so many more useless than needful things and you would easily be able to list more than 100 of them.

Counting aside, the existence of things you don’t need is true for most facets in life and – sadly enough – to an exceeding extent for enterprise software. We talk about features or rather an overload of aggregations of them. They conquer applications like viruses on computers infesting them like a severe disease: Featuritis. Unfortunately, there is no antidote or cure, it either hits you or you resist. Some do, as Horace Dediu reports, and you may be surprised who:

"We were witnesses to apps which appeared to be designed for users[!] They were not designed for committees that prepare checklists of requirements. We must applaud IBM for having the courage to resist the featuritis which plagues enterprise software design. This resistance requires saying No to those who specify and are thus authorized to purchase software and hardware. IBM has had to essentially say no to those who buy and yes to those who are paid to use. The quality of the experience is evident at first sight. The number of user actions, the number of screens to wade through have been ruthlessly culled. These are concepts and ideas which now permeate app design best practices. Yet they are practices which still elude the spec-driven enterprise software wastelands."

Markets define values
This gives hope but is still not reality in the everyday business of software development and enhancement. The central issue of raging featuritis arises from a fatal way of thinking. Software developers and their customers tend to think in terms of projects rather than products. What else is possible? What else would suit? What else can be done? Projects can be prolonged forever, products need a deadline and commercial viability, otherwise they cannot be marketed successfully. The market defines the real – added – value. Projects do not have value to the market.

Features becoming a plague
Then again, a software product doesn’t live a life of its own. Features and functionality will always be added. But for every feature or improvement request the programmer receives he should keep asking himself: “Is this really necessary? Does it help the user? Is there a better way to do it?” And he should always have the courage to say “No” if a feature is requested simply because it is technically possible. Of course, saying “No” is hard and sometimes leads to controversy. But the rule is – and always will be – it has to be a useful improvement not the fulfillment of majority voting. Make doing the easy things easy and the hard things possible. Otherwise it’s not a feature but a plague.

Resisting to featuritis temptations
As a reliable, cooperative partner to his customers a software developer will always be open to suggested improvements. As a matter of fact, most company software products literally exist from additional input of users and, after all, are a continuously growing summary of improvements – but most certainly not an uncontrolled augmentation of potentially possible features. At the end of his long, long day, an engaged programmer has only one goal in mind – not to fulfill the check-marks on a committee’s list of requirements but to commit himself to current as well as future users and contribute to their work-life becoming a brighter place. This is why he should resist to all temptations of featuritis. A stitch in time saves nine.

Christian Riege
The author is MD of cargo IT developer Riege Software International GmbH