
Why Enterprise Software Sucks: 6 Years Later - turoczy
http://futureofwork.glider.com/why-enterprise-software-sucks/
======
rjempson
Nothing like broad sweeping generalizations to make a good story.

I have a few points to make :

1\. End users have an incredible ability to complain that software doesn't
meet their very specific and peculiar requirements at any point in time. "Why
can't I print this expense report landscape on a5 paper, we have run out of
normal paper" - "Why doesn't this expense report sub-total by supplier and
week, but only in leap years?"

2\. If the people using the software were the business owners I think they
would sing a different tune, or go out of business because they spend so much
money optimizing for user experience.

3\. Enterprise software tends to be infinitely more complex than most Saas
projects. It is hard to budget and focus on the user experience when you are
processing billions of dollars in transactions, with complex business rules,
complex tax rules, complex laws, integrating with legacy systems, changing
business conditions and strategy. Most businesses will put compliance and
accuracy ahead of user experience.

4\. Non-enterprise developers seem to think they are shit-hot and have a chip
on their shoulders about enterprise developers for some reason. So you get an
endless stream of articles along these lines.

~~~
ucee054
"most SAAS projects" are not the ones setting the bar.

The _video games_ people set the bar. And they _are_ shit-hot. And they
produce stuff that even a 4 year old can use.

And the problems the video game people solve are more complex than your
typical schlubby entreprise app. In the case of MMORPGs, _infinitely_ more so
- and they have to deal with compliance and accuracy as well, because they are
dealing with stuff like credit card data.

The problem is that the entreprise software buyer is not the user, he just
gets to inflict the stuff on others - a perverse incentive.

I've worked on entreprise software in more than one big-name company, and I'm
embarrassed by what they ordered me to deliver. One time a friend of mine, who
had to use my company's malfunctioning stuff, even phoned me up at work to
curse me for it.

~~~
MortenK
You seem to be infatuated with the notion that "video games people" are some
sort of genius level software mavens, who can breathe fire and walk on water.
The boring reality is that the majority of game developers, excluding outliers
like Carmack etc, are young, novice programmers.

Games development is not some arcane area of software where only the "shit-
hot" developers may walk. It's simply a very special branch of software
development. You can of course find highly complex stuff in games (graphics,
AI etc), but if you look at enterprise, you'll find equal complexity just in
different, non-sexy areas like sheer code base scope, integrations,
performance requirements on transactions etc.

And if you look at "mainstream" SaaS apps you have yet again a whole different
type of complexity with the typically huge amounts of concurrent users,
advanced UI etc.

To argue about whatever types of developers are the best, is just silly and
frankly reminiscent of school yard discussions of which action hero could kick
who's ass.

~~~
josephkern
I believe the comment about video game developers concerns useability and not
fitness. I've been playing video games for many years, and from a useability
standpoint, game manuals have dwindled to nothing. If the game does not teach
me how to use the functionality during game play I really have no patience for
the game anymore.

Enterprise software should take a similar approach. Have something of a
tutorial mode, and an easily searchable text based document. Most of the cost
in the software comes not from the actual price, but in employee productivity
and training.

------
ams6110
Enterprise software does not put a huge priority on attractive graphics and
"discoverable" functionality, because people who use it very often tend to
perform the same transactions over and over and over. Efficiency in this use
case is far more important than e.g. something like HipMunk where someone
who's never seen it before should be able to figure it out without any help.

I was recently at my insurance agent's office updating my automobile insurance
coverage. The agent worked on a mainframe character mode interface and could
absolutely BLAZE through the various options and quote different insurance
options instantly. No dragging and dropping, no pointing and clicking -- her
hands never left the keyboard. Looking at the screen, nothing really looked
very pretty or intuitive. The system clearly would require some training or at
least some instructions to learn how to use it. But it works really well once
you invest that learning.

Then there are people in the enterprise who have to use this software
occasionally... e.g. people who have to file an occasional expense report, or
update their tax withholding. For those people it sucks, because there isn't a
lot of hand-holding, and the software feels clunky and arcane.

~~~
cmadan
The Bloomberg Terminal is a great example. There is nothing intuitive about is
at all and using the mouse with it is quite painful. (Here's what a news
screen in the terminal looks like [http://www.businessinsider.com/type-this-
command-into-your-b...](http://www.businessinsider.com/type-this-command-into-
your-bloomberg-terminal-and-youll-basically-get-theflyonthewallcom-2010-4))

However, every new feature we had to release needed to have every action
accessible using the keyboard. There were best practices for using certain
keys with certain actions (so that they were consistent across the features)
and this was one of the most important things of an UI review.

I ended up using the keyboard always whenever interacting with the terminal.
The Chief UI guy at Bloomberg was ex-Wall Street and told us that when he
started working on his first job on Wall Street, someone came up to his PC and
disconnected his mouse so that he would learn how to use the Terminal properly
and efficiently.

~~~
xorgar831
Intuitiveness aside, the other major issue with enterprise software is the
efficiency of use, and how out of touch it is with the task at hand. They slow
you down considerably IMO.

e.g. having to tell the app things it could just figure out, sloppy focus that
requires you to fuss with the UI, having to input a lot of text in small text
box that won't resize or spell check it, having to manually click a button to
auto-complete, modal dialog boxes that block you from reading important info
in another pane, uselessly vague or incorrect error messages for easily
correctable problems cause you to waste hours guessing what the real problem
is, returns no error message at all, oh you're using the wrong browser, oh to
attach a file in your enterprise webmail you need to install Sliverlight, oh
the web based wiki plugin for your enterprise document system only works on
Windows with IE, oh mobile browsers are not supported, let me slowly redraw
the screen a few more times due to some .Net + Areo legacy issue and hang your
window manager, supports Kerberos SSO but requires to you enter a password,
doesn't let you enter a username or password since it uses Kerberos SSO...
etc.

------
jwilliams
The reason Enterprise Software sucks is customization. Customization makes it
expensive, harder to test and impossible to upgrade.

However - Customization is what every Enterprise asks for. Sometimes they need
it, sometimes they don't. Customers and vendors are notoriously bad at picking
the difference.

SaaS offerings tends to be militantly "vanilla" with no customization.
Customization kills the margin for SaaS vendors. Whatever you think of
Salesforce in terms of their tech and approach -- this is the area where they
excel.

You can blame the "Enterprise" as much as you like, but these are structural
issues.

~~~
kyzyl
This. I dislike clunky enterprise software as much as the next guy, but really
sometimes customization is what you need, and the hip new basecamp-esque
players more often than not aren't willing.

Salesforce is a great example. My startup (may she RIP) had very intricate
sales channels, and we picked salesforce for our CRM because we could
customize it how ever we wanted. This was also before the big "SaaS boom", so
there were far fewer players in that space. Back then, salesforce was clunky,
slow and expensive as hell (I don't know what it's like now), but we could
manage our workflow end-to-end, all the way from trade show sales to
automagically managing ads and landing page rings. I'm not sure anymore, but I
would bet that's something that's still hard to come by.

------
steven777400
Also, it's complicated.

If I'm running a startup, and I have 100 customers using my product who each
have a wishlist, I can prioritize which of those wish items fit best with my
product and business vision, without excessive implementation cost or
technical debt, and proceed on that path.

On the other hand, in the enterprise, non-technical managers make business
requirements that are largely non-negotiable. Product complexity spirals out
of control as everyone wants their "pet feature" included, even if it
conflicts with other features, leading to massively customizable (and thus
even more complicated, to implement that customizability) solutions.

~~~
lmkg
I don't think you can point at management as the source of the problems. I
think the real source is the nature of enterprise itself: a small number of
large customers. When each individual customer provides enough revenue to
subsidize the development of their own pet feature requests, it's a plausible
business decision to accommodate, or at least entertain, those requests.
Blaming that on management seems to me to be shooting the messenger.

And the vendors that don't accommodate feature requests, lose business to the
vendors that do. Survival of the fittest is a cruel master.

~~~
mey
I agree with this, I am currently working in an Enterprise focused company and
I generally look at our job as being custom integration. Not because that is
the best way to develop software, but the best way to engage with these large
clients. It's how they want to be engaged. In turn you charge them
appropriately, help guide them away from the obvious traps, and have a
fundamental knowledge about what your domain expertise is. The last one is
important to know what to say yes/no too. It can be very profitable, but
frustrating from an engineering point of view due to the unnecessary
complexity created when multiple "vendors" are developing software to glue the
client enterprise together. Lots and lots of glue.

------
bcoates
This article claims that eventually, the companies will come around: that
"Companies are entrenched in their systems and don’t dare touch it if it’s
“working”" but eventually they'll come around.

Has anyone done any research on the opposite possibility: that most companies
simply ossify around the "acceptable" enterprise software when they're newer,
and don't so much adapt as die off, leaving room for more recently founded
companies that aren't attached to some ancient system?

The difference is of critical importance to someone trying to sell into that
market, it's the difference between being Mercedes and Unilever.

~~~
Spooky23
Does your software at your users site potentially contain taxpayer data from
the IRS or state tax authority? Congratulations, the implementation needs to
comply with IRS Pub 1075.

Does it potentially contain law enforcement data? Congratulations, your
customer needs to implement it in a manner consistent withs its CJIS
agreement.

Healthcare data? Hello HIPPA.

Up to a certain size, businesses can pretty much do whatever they want. Then
they reach a point or acquire a customer that requires them to start meeting
various regulatory requirements.

Ability to comply is a business opportunity. If I make software that contains
encryption that isn't FIPS 140-2 validated, I am missing out on a multi-
billion dollar market. (US and state governments + govt contractors)

------
dkrich
I think that a lot has to do with the writers and readers of those articles
having inherent biases that cause them to associate small and pretty with good
solutions.

I happen to fall into that camp and much prefer nicely designed Saas products
to legacy bloatware but I have been astonished to see time and time again that
other people I work with are not of like mind.

I once tried to convert my team to Asana because I love it for personal
projects and I naturally expected them to compare it to our current methods
and be blown away. I was surprised when it got nothing more than a "meh"
reaction and within days it was forgotten. The team actually _preferred_
SharePoint.

This also by the way is a case in point of why it is important to talk to
customers before building. Your assumptions about what is best are not
necessarily accurate. Small software sells well to small businesses and in a
lot of cases small teams, but company-wide (which I think is what we're
talking about here) takes a whole different level of sales and influence.

~~~
jrochkind1
I wonder if they actually preferred Sharepoint-- or if they just _didn't care
at all_ , and not caring preferred to stick with what they already knew how to
~workaround~ use, rather than learn something new.

------
holri
Enterprise Software is hard because the modeled enterprises are complex and
very different to each other.

This is a completely different beast than your toy App on your phone.

------
Zigurd
Before mobile apps can really become a model for enterprise software, their
level of sophistication is going to have to go up: Plug-ins, sync rather than
CRUD-over-IP, better use of Android modularity tools including ContentProvider
components, bound services, more intent filters, etc.

Right aspiration, but not enough great examples yet.

------
AndyNemmity
I work in Enterprise Software. What you said has relevance in some companies,
and is completely different in others. Really hard to make broad
generalizations like that.

Mobile Apps are now a huge part of Enterprise Software. Adoption rates are
high in the younger people, and lower as the age climbs.

The average age of the people in the vertical (Retail vs. Oil and Gas) have
much more to do with the adoption rates than Enterprise Software vs. startups.

There's a lot more I could speak to, but I don't agree with so much of your
premise that it's hard to figure out where to focus.

Even the questions aren't clear. Should we focus on ERP/CRM systems as the
basis of the question, or across the whole enterprise? They are very different
questions with different answers, and adoption rates.

------
greedo
Good enough is the enemy of perfect.

One of my duties is managing my company's backup systems. We use NetBackup,
and despite it having a pretty old codebase underneath, it works fairly well.
However, its interface is right out of 1998. Usability features you would
expect in a modern program are just missing.

Where it shines is in its ability to script/automate a lot of tasks. Users who
only use the GUI are surprised to see that their list of annoyances aren't
really valid; NetBackup just doesn't put as much emphasis on shiny.

~~~
josephkern
Perfect is the enemy of productive.

