I can only recall one application that has removed, not added, features during an upgrade. The product was Starfish Sidekick and, surprisingly enough, I (and many users) welcomed the removal because it resulted in a leaner and faster product.
That remains a one-of-its-kind experience. Typically software is packed with more features than the average user (and increasingly even the expert user) can master.
Excess baggage
As early as 2001 Gartner was warning organizations not to overspend on their application server. Gartner found that organizations were buying high-end products to run simple JSP or servlet-level applications. More than a billion dollars had been lost in the process.
If anything, the trend is accelerating, as developers tackle more complex projects. Still at what point do we cross the line between powerful tools and too powerful tools? Big is not always a quality. Being the largest boat of its time, did not prevent the Titanic from sinking.
There are many reasons that push us to overbuy software but the most important ones, in my experience, are lack of experience, feature lists and the push to enterprise software.
Software projects typically involve an element of novelty. It is not obvious to judge which features are important and which are not in our tools. It seems more prudent to overbuy than risk lacking an important feature.
So we shop for the product with the longer feature list. The longer list, the better or so the reasoning goes. Unfortunately features that are not used still end up costing time (training, deployment and maintenance) and money (license fees and hardware).
Lastly the industry suffers from an enormous marketing drive towards so-called enterprise products. What differentiate an enterprise product is that it is supposed to handle the most demanding tasks, as found in large-scale projects.
There is no discussion that large projects need the sophistication of enterprise software (in fact, they often need much more) but it does not derive automatically that other projects, e.g. departmental, will benefit from the increased sophistication.
Software is like a pair of pants. If it does not fit, it’s uncomfortable.
Small is beautiful
Sherlock Holmes once claimed he was neither optimistic nor pessimistic but realistic. How to be realistic when shopping for software? I do no have a foolproof solution I have found the following two safeguards help:
- talk to the user. It’s a cliche but it works.
- evaluate open-source products.
A conversation with the users is a sobering experience. Even when you excitedly point them to the latest buzzword-overloaded products, their focus remains firmly on the job.
The impact of open source products may be less obvious but it boils down to this. In general, open source packages are more specialized than their commercial counterparts. I suspect it’s because the users are closer to the development. It’s hard to motivate a developer to put a lot of effort into features that he is not using, does not intend to use and knows very few will ever use.
Just as an example, consider the web server. You can’t buy one anymore. You have to buy an high-end application server, a database or an operating system. You can’t buy one but there are many fine web servers distributed as open source. The Apache HTTP Server and Jetty are my personal favourites. Both are excellent packages, focused on serving pages.
Evaluating open source software early in the process, addresses the three issues I raised earlier: it lets you gain experience with a class of software, it allows you to make more informed decision rather than be guided by the feature list and it is less likely you will be pushed into entreprise products, unless you really need one.
Note that whether you end up using open source projects or not is irrelevant. The main benefit is to gain hands-on experience with a certain class of tools.
Right-sizing
I hope I have convinced you of the importance of choosing tools that are appropriate to the needs of your project. To help you understand the needs better, consider these two safeguards: talk to the user and evaluate open source packages.
Benoît Marchal is a Belgian writer and consultant. He is the author of XML by Example and other XML books.
He works mostly on web services, XML and Java.
