When deciding what package of software to purchase, or to decide if you should build your own solution, it is common to hear the question: “does it give us more than we actually need?”
Example: you run a small business with a single cash register. Do you need a cash register solution that can run on a network, or that requires a login, or tracks inventory? Each of these are key features, but perhaps one of these features is not important to you,
So, you could decide not to buy the ‘high end’ system and instead buy a less capable system to save $250. You may feel pretty good about it… until you need to add another cash register.
Of course, you could ask a more sophisticated question: are these features we may, someday, need? What is the value of a feature you will never use, after all? If you were to ask that question, then software that can handle two cash registers on a network would be valuable, even if you only have one register (today).
But what is the actual cost of NOT getting the capability? What is the cost of building a system of your own just because the commercial package is too capable?
From experience, you would be nuts to build a system when you can buy one that meets your needs, even if the system you buy gives you capabilities you may never use! Even if you have a team of developers in China offering to build your app for pennies!
As long as a commercial app covers a very large percentage of your needs (80%+ of the function points, for example), then buying beats building, hands down, even if your needs account for less than 40% of the systems’ capabilities.
Reality check: the cost of owning a custom application is high. It is the cost of collecting requirements, managing the project, rolling out the software, maintaining expertise needed to fix it when things change (as they always do).
It is the cost of upgrading platforms as developers become scarce. It is the cost of backup processes, restore trial runs, helpdesk staff and software, and other infrastructure, both human and technical, that is needed to keep custom software “up and running.”
I suppose it is feasable to say “why buy SAP when a simpler package, like Dynamics, is available for a fraction of the cost.” I would agree, as long as the package you choose actually meets your needs. You should absolutely go with the least expensive solution that works.
On the other hand, never assume you can write in a weekend.
Rule of thumb: Cover your needs and a little bit more. Whatever else you get in the box… it’s free.
2 thoughts on “Can your software be TOO functional?”
Nick. I agree that the COTS solution with excess functionality is often better value-for-money than a home-grown solution with just-enough functionality.
But although the excess functionality may be cheap, it usually isn’t free. It typically carries a performance burden; it may introduce additional security problems (think of the vulnerabilities that macros introduce into MS Office – and how many people actually use them?); you may find yourself installing patches that are irrelevant to the functionality you are actually using; and you may need additional governance (to prevent accidental or inappropriate use).
What I really want is the option to plug in extra functionality as I need it, not having the extra functionality already cluttering up my system.
Excellent point, Richard.