Why Enterprise Software Sucks
37signals.com
37signals.com
As I entered an order, I asked, "How do I find my Customer Number?"
As I entered a part number, I asked, "How do I see how many are in stock?"
As I scheduled the order, I asked, "How do I see the current factory schedule for this item?"
It drove the salesman nuts. He couldn't explain how to do anything without grabbing the keyboard.
I asked, "What good is this system if I can't even enter one order?"
His response..."Are you going to train your people or not?"
That's pretty much their attitude. He was so upset with me, he went directly to the CEO, who asked me what was wrong. I handed him one of our orders and said, "If you can enter this order into that system, we oughta buy it." He couldn't. We ended up buying another system that people could use.
The dinosaur is big, but it is dying. Hack on, and let the one who delivers the value win.
The bigger problem is that the buyers have already spent god-knows how much other money on dozens of software solutions that all were supposed to walk on water. Now the poor schmuck writing some simple app has to take into account leveraging all that other previous investment by the organization.
Ever buy Enterprise Software? Every vendor loads that stuff up with so much junk that it's a wonder they can fit it all on a stack of DVDs. Most of them can do everything but the laundry. And for each of those purchases, there's some executive somewhere wondering "why aren't they just implementing that software we bought last year?" -- it quickly becomes a political process where nobody wins. It's not a simple users-aren't-the-buyers situation. Even if the users were the buyers, you'd still have the same situation. EDIT FOR CLARITY: That's because there is no single user with a single set of needs. Such situations rarely exist. It's more complicated than that.
Because buyers aren't the users, enterprise software companies must stuff in every possible feature they can. We all know that more features != better system.
We're still stuck with the question of why stupid things like comparison charts exist though. It all comes down to accountability. Buyers need to have something to cover their asses if the system doesn't work out. "See, look at this comparison chart - I bought the best system out there. Just look how many more features it has."
And let's not forget that even if you make the buyers the users, even a really small number of users will have conflicting requests for features. You could give everybody in the organization fifty bucks to spend. That would make the buyers the users. But what would happen? Everybody would be happy that they'd solved the 3 or 4 things that were most important to them in the simplest way possible. The remaining situation would be lethal for the larger organization: loss of reporting, command-and-control, re-use of data, standardized products to train newcomers on, etc.
In the end, it's a choice. You can make "solve the simple problem" programs and sell them to lots of users who will then create chaos in the organization (because they fix only the perceived immediate needs of a subset of users) or you create feature-rich, bloated software that does everything for everybody and that's hard to use (and possibly impossible to adapt) but is attractive to the larger organization. Companies have been making lots of money on both of those options.
Put a different way: users in an organization have immediate, day-to-day needs that only reflect a very small part of the greater needs of the organization. So somebody has to compromise. There's no free lunch.
But that's not going to make you a lot of friends. :)
On the plus side, if you actually create simple to-the-point software, your users are probably a smarter breed of cat (read: less support costs?).
I wonder if this dissonance between what businesses want from an ERP system and the capabilites of ERP systems is due to programmers desire to elegantly abstract and generalize software. Businesses want ERP software to be specific to their business. Motorola, Nokia, GE, Sam's Muffler Shop do not want to be generalized into MyAbstractBusinessClass.
I couldn't disagree more. I don't know how many enterprise systems I've worked on that are unnecessarily complex.
The trick is not to deny complexity or embrace it. The trick is to make rational compromises. Start with something simple and add just enough bells and whistles to get most of what's needed done. But that's a much more painful and difficult process than just buying some big product off the shelf.
The problems that enterprise software system really try to solve are masked by trying to genericize them for every situation and everyone. It still comes down to solving one specific problem and solving it well.
That's why "project management software" isn't the same as "software to help us plan and control building and deploying industrial power transformers in a union environment where we have high governmental reporting obligations" or some such. Companies either want to sell generic products with feature bloat all over the place, or home-grown shops try to take fragile systems and glue them together with more and more code. Either way you end up with a lot more complexity than the organization needs.
But it still might not be a simple answer. And nobody wants to do the work of figuring out what the minimum amount of complexity is for each situation. (Even though there's probably more money in that than anything else)
As much as most enterprise software sucks, it's at least 3 times as bad trying to install or upgrade it.
Enterprise software companies know their customers have deep pockets, which is what support contracts are all about. They purposely make the documentation too confusing or too sparse so they can push the "value" of their yearly support contract. Once you've bought the basic support contract, they tend not to have many more answers than what you can get from the documentation. Of course, you can buy higher levels of support where they'll send someone to be onsite to work on your problems (which means even more money).
By this time, you've already spent so much time and your manager has spent so much money on this stuff, that it's too embarrassing for your manager to admit to his bosses that he's made a mistake and your stuck with the crappy software.
This group of people have no idea or whatsoever the requirements of an enterprise software. All they know is how to create a beautiful websites. I'm not saying that sarcastically, I like beautiful websites.
But this group of people judge the quality of the software from the UI perspective; if UI == sucks then software sucks. They believe that a wonderful UI == best quality software. That may be true but it's a wrong generalization.
Not to mention that web-designers and 37signals NEVER work on any enterprise software. They simply work on small projects because it's their specialty.
A friend of mine works in a company that develops airport traffic control software. More than one time I heard him say how the features that are pumped into the software are not features that are wanted by the users, but by managers that are responsible for buying the software.
In telecommunications, where I have a little more experience, it is similar. Things that we were supposed to work on are not the things that people required. I spent a whole year on a team of 15 SDEs developing a bunch of "features" that would never be seen or used, but that had to be developed if you want to have a Class-5 Phone Switch that complies with Brazilian regulations.
Of course, when I refer to 'him' I am completely ignoring the tragedy of the commons dragging down every any large-scale enterprise[1] over time.
Enterprise software is just an extreme example of these two phenomena.
[1] no pun intended.
Mind you I'm not the only person that dislike Basecamp.
http://www.whybasecampsux.org/
NB: My current office uses Basecamp but I never bothered to open it unless there is a message for me.