Slashdot Mirror
Business Software Needs A Revolution
An anonymous reader writes "According to a Businessweek Online article, today's high-end business software is bloated, buggy, and too expensive - no surprise to those of us who have paid our bills by adding pointless features to some piece of software arbitrarily priced at $100k. Evidently, firms are now re-evaluating their software purchases, and finding that they're not working out the way the sales guys told them they would."
"There are some companies out there (M$ being the prime example) that don't add much in the way of new functionality, but rather repackage things, move buttons and menus around and make the new incompatible with the old. At the same time they only fix certain bugs, but leave others alone. Yet people buy their crap at record rates."
To be fair, Microsoft do add functionality and bug fixes to new releases. Few would argue that driver handling in Win XP (to name just one thing) is not a huge improvement over the way driverws were handled in Win 98. Despite the Fisher-Price GUI (which one can change back to the old Windows look, thank God), I'd say that XP is a pretty decent OS for home use. But would people upgrade to this new OS purely to get rid of some bugs and problems?
The market is demanding new bells and whistles. How many people would purchase a new version of MS Office, if it would look exactly the same as the previous one, and didn't add any new features? I've been to Microsoft sales presentations. All the people there, like me, were there to make a decision for their company to purchase the latest & greatest to come out of Redmond. You should have heard the Ooohs and Aaahs as each new (and completely pointless) feature was presented.
In fact, I firmly believe that new features and a new look and feel go a long way toward convincing potential buyers that all your old bugs and issues have been fixed. You'd expect the opposite... new features mean new bugs, but no. If you're in the software business, you might want to try the following experiment when you roll out a new version of your product: give half your customers the new version, but with the same splash screen and GUI as the previous version, and give the other half exactly the same new version, but with a different splash screen and with a new look-and-feel. (Redesigning the button icons will be sufficient). Then ask all the users to fill in a short customer satisfaction questionnaire, asking how this new version performs compared to the old one. Does it perform better, meet their needs better, has less bugs, etc. You might be surprised by the outcome...
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
The blurb that was submitted puts an unfortunate spin on the comments. It's not so much that marketing told them the wrong thing -- it's a failure of management to fully identify and evaluate their needs. I've seen it happen time and time again where a million dollar project gets flushed down the tube a year later because no one is using it anymore. The software works fine -- it's just that business priorities weren't quite there to get everyone on the system and plans changed. In some cases, the product is flawed and full of bugs, but most of the time, the product doesn't suit the business requirements.
Someone hates these cans.
I'd kill for direct access to the underlying DB or a nice clear way of moving data in and out, or a great way to make custom GUI... but the company is more concerned with ensuring that we are locked in FOREVER than with providing the tools we could use to make their software more friendly to our over all IT enviroment.
J.D. Edwards has a design that accommodates things like a custom GUI. In JDE, the business logic of the "system" is implemented in a layer of "business functions". These are API function calls that perform the usual create, update, delete operations, but at the level of business abstractions, such as documents (orders, customers, etc.) All of the necessary validation is performed in these functions. The APIs are documented and there are several thousand of them. The APIs are then exposed through multiple mechanisms to the developer (C libraries, Java objects, XML, proprietary forms/report methods, etc.) This design provides the developer with a means to wrap the full functionality of the system in a custom interface, with the same validation as the vendor provided interface.
The only problem with the JDE system is a lack of solid documentation on the interaction of all of the functions. A single business "document", such as an invoice, may involve a minimum of 6 business function calls. Exactly what calls are necessary, and in what order, is not public knowledge, as far as I know. You can discover it by examining system source code or doing debug traces, but that's a major roadblock in some cases.
Maw! Fire up the karma burner!