
Why Enterprise Software Sucks - libpcap
http://37signals.com/svn/posts/669-why-enterprise-software-sucks
======
dasil003
Jason didn't dig deep enough on this one. _Why_ is the buyer not the user?
Because enterprise operations are too big and complex for any one person to do
the job.

Likewise, there is no one person that understands how the processes work or
even why they all exist. This makes the job of enterprise software development
incredibly difficult, it also means that individual stakes are smaller, and
the law of averages makes it much more difficult for anyone to rescue the
project and pull it above the fray.

Now consider the demand for qualified software developers, the glut of
incompetent developers, the difficulty of identifying which is which for the
non-technical hiring manager, the variety of world-changing and otherwise sexy
jobs available out there for quality engineers, and it's no wonder enterprise
software isn't as good as small boutique software like Basecamp.

I'm happy for Fried and company that they were able to dodge the enterprise
software world even more deftly than they maneuvered themselves free of a
different scourge of the creative persuasion--client work--but this article is
a bit too self-congratulatory without offering any real insight or potential
solutions to the very real problems that large companies face.

~~~
pkaler
_Jason didn't dig deep enough on this one._

Jason Fried didn't author this article. It's credited to Zubair Hamed.

~~~
umjames
He did author the article, the latest by Zubair Hamed is the name of the
latest commenter of Fried's article.

~~~
GFischer
Ironically it's not as easy to understand (bad user experience?) - I would
have been misled as well if you hadn't pointed it out.

------
thesethings
I think 37signals is half-right, but the other part of the dynamic is that
enterprise software is "hidden," while consumer/web software is public.

Things suffer in the dark longer than they suffer in the light.

HP/IBM/BMC web interfaces for (intranet) products sold _this year_ would be
laughed off the public web in five seconds (really bad frames, client-side
Java applets, etc).

(Not to mention the poor organizations buying this stuff tend to have it for
about 5 years post-purchase.)

That said, the dynamic is changing. Enterprise software/IT is getting
consumerized. Sometimes unofficially (everybody uses their ipad at work, but
gets/expects no help), sometimes officially (Google Apps has been adopted by
some big organizations. Its enterprise product is slightly different from the
consumer Google apps, but it's really dang close.)

Big business aside, I believe about 10 million students use Google Apps as
their _official_ collab/email tool (not counting people's personal accounts.
And Google adds a few big schools every month.). These students simply won't
arrive at their jobs post-graduation willing to use Lotus Notes + .doc
attachments.

Younger workers aren't the only thing leading to the consumerization of IT,
there's a lot of influence coming from the Internet, and consumer hardware.

I don't want to hijack the thread, feel free to crawl my profile to find other
places where I write about this stuff. Consumerization of old-school IT is my
new pet area of research.

~~~
yardie
_Big business aside, I believe about 10 million students use Google Apps as
their official collab/email tool (not counting people's personal accounts. And
Google adds a few big schools every month.). These students simply won't
arrive at their jobs post-graduation willing to use Lotus Notes + .doc
attachments._

Haha, want to bet. They'll use whatever is expected because for some places
Gmail isn't an option. Maybe in 10 years when some of these students have
titles like SVP they can migrate to other platforms.

~~~
thesethings
Heh. I should have been more clear.

I've "onboarded" (enterprisey word for
orienting/registering/supporting/creating accounts for new hires) many new
employees disoriented/frustrated by their new org's tools.

What often happens when a new hire really disagrees with his/her new tool for
task is that they only use it for the "last mile" of the transaction.

So... say they have to turn in an expense report in Excel template. But they
like some other app. They will take all their notes in $preferred_app, do all
their editing in $preferred_app, and at the last step, export to Excel
template.

You should see the machinations I've seen around mail. Convoluted downloading
and parsing from Exchange servers with shell scripts... hah.

In any case... this is not ideal. What this does is make users absorb
complexity for IT. IT can get comfortable wtih a platform, too leery to try
something else. But users, often years into new generations of workflows (not
just young people, so many older employees have been using Gmail for years in
their personal life for example.), absorb the blow.

------
patio11
Perhaps Enterprise Software sucks because it is really, really hard? Your
mission, should you choose to accept it, is to reduce the most complex of
human institutions, which has processes beyond number -- many of which are
documented only in the heads of the dozens of geographically disperse
individuals carrying them out, or worse, actually _emergent behavior_ \-- into
a CRUD app. That CRUD app will, by necessity, be orders of magnitude more
complex than any other shipping product created by the human race. And
everything changes so fast (emergent behavior, thousands of autonomous actors,
etc) that it is unlikely to remain static for the duration of the planning
meeting to say nothing of the multi-year timeframes often planned for (or
stumbled into) in this type of development.

------
gvb
I spent 25 years in a big company tolerating crappy software. Jason is
absolutely 100% dead-on correct.

 _The people who buy enterprise software aren’t the people who use enterprise
software._ ... _[T]he software vendors are building for the buyers, not the
users. The experience takes a back seat to the feature list, future promises,
and buzz words._

Enterprise software is bought on marketing bullet points, as long as the
budget can bear it (cost and quality for enterprise software are totally
uncorrelated). The buyers have no ability to judge the _implementation_ of
those bullet points, so a crappy implementation sells just as well as a good
implementation.

The other observation I would offer is that the level of effort required to
initiate and carry through the purchase of a new software package is _so high_
in a large company that nobody can _afford_ to make a mistake (time/effort-
wise, mentally, and career-wise). Thus, only "safe" choices are made.
Ironically, what appears to be the safe choice very often _is a mistake_ \-
crappy buggy implementations of huge bullet lists of mis-features.

Sorry for venting. :-D I'm much happier in my new _small_ company where we are
willing to make several small, recoverable mistakes (base hits, bunts,
sacrifice flies which advance the runner) to score a run rather than swinging
for the fence and being out on a fly ball every time.

~~~
gaius
Nah, that's not actually true, and only someone who knows nothing about how
enterprises actually work would think that.

That SAP billing system you hate? The CFO uses it too, to run his dashboard.
That crappy Exchange email? Drives the CEO's BlackBerry. The godawful IMS
database? The CTO's bonus is tied to its uptime.

There is more to computing than Rails-driven websites, I don't think the
37signals guys get this.

------
jcromartie
In my experience, there is _one_ single point where enterprise software takes
a nose-dive into an unusable mess, and it's _access control_. Access control
ends up being all of a business' BS politics _encoded_. You end up with
"requirements" like this:

    
    
        * Bob can't see Sally's actions
        * Sally can see Bob's actions
        * Jim can see Bob's but not Sally's actions
        * Jim can't do X, unless Bob says so
        * Bob can't do Y, unless, Jim *and* Sally say so
    

It's all about politics and procedure, not the actual work to be done.

There's a cure to this: Make every action in the system open and accountable
and let people get things done. If someone does something they aren't supposed
to, then undo it and discipline them.

Obviously there are some areas where (like transferring money or publishing
content) where permissions are perfectly reasonable, since you don't want
disgruntled employees siphoning off money or publishing disparaging remarks.
But, then again, we hear about management (the super-users of enterprise
software) doing that kind of damage pretty frequently, too...

------
ryanwaggoner
Well, to be fair, Jason does advise developers to just solve small, easy
problems and let "someone else" tackle the big, hard problems.

I wonder if Jason has ever worked with real enterprise software, either as a
user or a developer. The reality that he seems to miss is that the enterprise
software arena is full of big, hard problems that have huge dollar figures
attached to them. But I suppose that's why Oracle is worth more than $100
billion; they're that "someone else".

~~~
aaronblohowiak
Yep. You can't chose which corner cases you're going to support. The answer
is: "All of them." The difference is how gracefully you handle that, and the
support that you provide for the end-user of your application.

Further, enterprise software sucks for casual users, but is often superior for
expert users than consumer software that is less featureful and robust. I
think that depth vs learning curve is a bit of a false dichotomy, but
complexity geometrically increases difficulty in making "intuitive" software.

~~~
yxhuvud
On the other hand, complexity also geometrically increase the payoff for
successfully making intuitive software.

~~~
aaronblohowiak
in some markets

------
moron4hire
I think this is a lot of confirmation bias. Everyone has their story of
cheese-head corporate IT managers making bad decisions. IT managers are like
air, you only notice when they stink.

Unfortunately, I left a company with a good IT manager for an "opportunity to
grow" elsewhere. Sure, I got a higher salary, and I got to move to a new city
(this is the most compelling reason that I stay right now, I like my location
a lot), but it's definitely one of the worst ad-hoc development environments
I've ever been in.

But my previous position had a great IT manager. We took a very well defined,
engineering approach to purchases and development. Identify need, research
alternatives, implement, iterate. I learned a lot in a mere year and a half,
more than I ever learned in college. It makes me wonder what I'm going to
learn in the years to come.

~~~
umjames
You actually did development? In my current IT job, 90% of it is
installing/upgrading vendorware (closed or open, as long as it's Java-based).
The other 10% is writing the pieces of glue code needed to incorporate the new
vendorware with the existing vendorware. That's not what I call development.
It's closer to a web-centric, glorified sysadmin job.

Now that I think of it, the real problem with enterprise software and the IT
departments that rely on them is more about the fact that IT departments don't
seem to actually create much software, thus they're not that good at it.

This means that when talented people start working there with the hopes that
they'll get to create something interesting (or at least in an interesting
way) and they find out that the organization won't allow them to do anything
novel, they leave.

~~~
moron4hire
Yes, I was actually developing industrial crane simulators of various types
for the company's product line, so a significant portion of original
development was necessary.

------
cageface
Enterprise software is bigger and clunkier and more awkward for the same
reason that big shipping liners are bigger and clunkier and more awkward than
speedy sailboats - it's designed to solve a different problem. Don't make the
common mistake of assuming that everybody working on these kinds of apps is
stupid and/or incompetent.

The more interesting question to ask is - are we solving the right problems?

------
10ren
I've been doing _customer development_ this week, and one benefit to thinking
in terms of separate economic buyers and end users is that it helps you to
consider their relevant issues separately: usability and usefulness.

Because I use my own software, I'm very aware of how easy (or not) it is to
use, and of course I'd really like to make it great to use. But in doing this,
I tend to overlook _what_ it's doing. What does it _do_ that makes it worth
buying? Separating these issues into different persons makes it easier to
think about them clearly (especially when the usability one is so concrete,
immediate and, well, personal.)

Also, when the user and economic buyer are combined, people will sometimes buy
based on how beautiful it is, how it feels and so on. But I would like my
product to actually make things better, not just make them feel better. Both
are important (and of course it doesn't excuse enterprises who build/buy
inefficient and unpleasant software).

------
mburney
There was a point in time when 37 signals was inspiring with their anti-
enterprise/ror/bootstrap ideas, but do we really need to hear the same thing
repeated over and over?

Edit: didn't notice at first that this blog entry was from 2007. Anyway credit
to them for making this point so many times that it is now a widely accepted
belief in the startup community. But now there is just as much uninspired non-
enterprise software out there too.

------
rivo
I work for a company which develops software for airlines. Our product is
bought simply because it makes them 1.8% more revenue per year. We could have
the greatest user interface and it wouldn't matter at all. The users are
ignored. I've seen customers replace users because they had a hard time to
adapt to the interface of the new software. Sad but true.

------
wglb
Good article, and there are lots of good comments.

Some things not said include:

* Some enterprises have nearly 50-year legacies.

* Existing systems are often complex enough that there isn't any one person anywhere who understands it technically, let alone from a cultural perspective.

* The people making the purchase decision aren't even the _users_ of the system. Imagine a company big enough that it is the legal team that makes the decision on which BFE package to purchase. The deciding criteria would not amuse you.

And there is the idea that what we, readers and writers of HN and 37 signals,
don't always appreciate that a nice UI might actually be a green screen 3270
application. The CICS screens have the side effect of being keyboard
navigable, and therefore are higher throughput than today's idea of mouse-
driven beauty. (Not to go all Steve Yegge on you.)

Finally, selling the _same_ BFE software to multiple enterprises is usually a
pipe dream. The technical input to the negotiating team can result in a line
item in the purchase agreement that is "custom modifications", and which of
the salesmen hired by Mr. You-have-to-be-an-idiot-to-not-read-the-resume in
the last few hours of the negotiation is going to say "no" to that? So all of
us in this particular negotiation--customer rep, technical rep (note that I
did not say "development"), compliance rep, and legal rep buy into this, each
with their own motivations. You can see how well that works out.

------
akeefer
He's right that the buyers not being the users is an issue, but there's far
more too it than that. There are a lot of good answers already here, but to
add a few more (and consolidate some others):

1) The developers often aren't the users either, which instantly makes things
far more difficult. My company builds insurance applications; it would be 10x
easier (if not more) for me to write an e-mail application with a good user
experience than for me to write a policy administration system with a good
user experience because I'm not an agent or underwriter. With consumer
software, development or collaboration tools, and a lot of small business
software, the developer might actually have to/want to use their own stuff.
For most enterprise software, that's rarely the case.

2) As has been pointed out already, a lot of enterprise software is complex.
It's hard enough to get everything to _work_ , let alone to have a really
nice, slick UI. There are often endless numbers of non-optional corner cases
to handle. If you're really unlucky, the process in question will be subject
to lots of government regulations you have to abide by; if you're even
unluckier, those regulations will vary by state (not to mention by country).
It's hard to make something that complex user-friendly.

3) In addition to complication, there's the issue of surface area, which is
somewhat orthogonal. It's much easier to polish a web application with 20
different screens that to polish one with 2000, no matter how simple those
2000 are; you often don't have the resources to devote huge amounts of
attention to detail on an application with that kind of surface area.

4) Enterprises themselves are difficult to sell to. Extremely difficult. It's
largely a self-inflicted wound, but it results in an increased barrier to
entry in that market, which increases the cost of actually selling into that
market, which leaves fewer resources for development (relatively speaking).

5) Enterprise systems often need to integrate to a bunch of other enterprise
systems. Any way you spin that, it's difficult and time consuming to do that,
which sucks up more resources.

6) Most enterprise solutions involve a lot of vendor lock-in. That's partially
due to the storage of large amounts of highly critical data, partially due to
general risk-aversion at most companies (since such changes, if they're
botched, can be disastrous), and partially due to the integration work
mentioned above. The cost of switching tends to be very, very high.

7) Everyone wants to be a unique snowflake. For core business processes many
companies consider their process to be a competitive advantage; at the very
least, it's a core part of their business. As a result, enterprise software
often has to be customizable so it fits with what data the customer captures
and how they do business. That dramatically ups the complexity factor and
makes polishing things much harder.

8) Because of all those factors, enterprise markets have a high barrier to
entry. The complexity of the products means that you need a decent amount of
funding to even begin to enter the market, and the sales difficulties suck up
more money and make it difficult to establish a consistent revenue stream. The
relatively small market sizes combine with that to turn many of the markets
into winner-takes-all sorts of games. As a result, you end up with two classes
of companies: new entrants and incumbents. The new entrants don't have the
resources to really polish their stuff; they're struggling to build stuff
that's functionally complete, actually works, and to sell it without running
out of money. They can't afford to chop their footprint in half in order to
make sure it's really slick, or to spend twice as much on development. The
incumbents, on the other hand, often have no incentive to not suck. They tend
to have high levels of lock-in and they know their competitors have huge
barriers to entry, so the competitive pressure to be good isn't there.

9) The most talented developers and designers often simply won't work on
enterprise software. You're working on something you wouldn't use and have no
personal connection to, and no one you know can use or see your work. At least
in the valley, if you tell people you build enterprise software, people often
react like they feel sorry for you, or like you're some sort of idiot-leper
who simply isn't good enough to get a job building cool consumer stuff. Ask
awesome developers if they want to work on a database, a social networking
site, or a claims processing system, and I think we all know which option will
come in third place.

10) Those are all reasons why commercial enterprise software written by
software companies sucks. A lot of enterprise software, however, is written
in-house. If a company that can amortize their costs across dozens or hundreds
of customers has a hard time doing it, you can imagine what happens when one
company attempts to build things themselves. They really don't have the
resources or expertise to product anything thoroughly polished most of the
time. And the hiring problem there is even worse: most good developers would
rather work at a software shop than in the IT department of some massive
company.

~~~
saikat
On your point #2 - it is true that enterprise software tends to be complex,
but this problem is compounded by the fact that enterprises are unwilling to
approach building/buying solutions to complex problems with a conquer and
divide approach. In the consumer/small business world, small, lightweight
tools that solve one problem well(think Redis for databases, Etherpad for
collaborative editing, etc.) are easier to make good interfaces for.

When it comes to buying software, big companies don't like choosing small,
well-designed tools that they can put together to solve a problem because the
decision-making process of choosing technology is expensive and time consuming
when you are risk averse. At a large financial institution that I used to work
at, we spent months going through different third-party offerings of a new
data platform. Everyone hates doing it, and it cost a ton of money in
developer time (plus some companies actually charge you to do a lengthy demo).
So people just tend to gravitate towards the products that are bloated with
features and will solve all our problems at once, and we all know what kind of
UX these kinds of products will offer.

~~~
nradov
Integrating a whole bunch of small, well-designed tools is just as expensive
and time consuming. And the final results are often worse.

~~~
saikat
Maybe or maybe not - my point is just that this is one way you get tools with
good interfaces, and it is less likely that you will take this path when you
are a large company.

------
ebiester
Further, enterprise software often has less than a dozen customers. If you
work on Word, you have millions of people paying a little bit of money, but
that adds up to a large budget. An enterprise system with ten customers paying
a million a piece? That's only a 10 million dollar budget. Further, each of
those customers need slightly different applications to fit their business
models. It's ugly, even with good architects.

The money just doesn't exist to obsess over UI in these products.

~~~
ebiester
And yes, there's huge opportunity here for someone who figures out how to
overcome this problem in multiple ways:

1\. Someone who develops a uniform beautiful interface and a great development
kit. ExtJS is on its way.

2\. Someone who figures out how to solve that 10-very-close-but-not-quite
appplication problem in a more elegant way than spring.

~~~
protomyth
You still need to spend a lot of money on lawyers and accountants to get the
local and international laws correct.

------
mpm
Not exactly original. It would be less offensive if he labeled it something
other than "My Take"

[http://lists.canonical.org/pipermail/kragen-
tol/2005-April/0...](http://lists.canonical.org/pipermail/kragen-
tol/2005-April/000772.html)

~~~
dasil003
That's a massively superior article, but what makes you think that Jason read
that?

~~~
mpm
A month earlier someone posted a link to the same email as a comment to a
different 37signals post

[http://37signals.com/svn/archives2/define_enterprise_in_10_w...](http://37signals.com/svn/archives2/define_enterprise_in_10_words_or_less.php#c9633)

~~~
btilly
A link posted last month does not explain a 37 signals post from 2007. (Though
I must say that it does seem very similar, and that email did get wide
circulation.)

~~~
mpm
Not last month, a month earlier than the post in question. Check the
timestamp.

------
blogimus
For some reason I had a sense of deja vu on this exact topic, so searched the
archives and found this (from my earliest days lurking before I signed up for
an account on HN)

<http://news.ycombinator.com/item?id=72115>

------
lars512
The article: because the buyers aren't the users

Nice comment below the article: because accommodating the long tail of user
requirements is too expensive to be worth it, so they make a cut somewhere,
get something good enough for 95% of employees and squeeze everyone else into
the same box.

37 signals doesn't try to accommodate all user requirements either. They're
free to tell people to go somewhere else if their tools don't suit. In an
enterprise, they save costs by standardizing. People would no doubt be just as
unhappy being squeezed into the 37 signals box as any other.

------
forgotAgain
There are a lot of reasons why enterprise software sucks.

The largest reason is because companies see it as an IT issue. When it comes
time to select software to purchase most departments will not invest the time
of their best people. The people who can most easily be spared for the amount
of time involved are put on selection committees. Users don't see selection as
an investment in the future but as work that doesn't help them today. So in
answer to Jason's basic point: users don't select enterprise software because
they don't see selection as an important use of their time.

The next largest reason enterprise software sucks is because people don't want
to change. They want new software to work the same as old software so they
don't have to learn anything new. It is the main reasons why there is so much
customization work. Its a combination of people being lazy and managers not
wanting short term efficiency ratings effected.

------
ryan-allen
Enterprise software certainly doesn't suck due to companies hiring mediocre
programmers who cargo-cult vendor technologies (open OR closed source),
hoodwinked by clever marketing, catch phrases and shallow promises of
increased productivity?

------
teyc
Enterprise Software is old, very old. And old software is hard to change, even
from a UI point of view. There are already thousands of users trained, and
changing the way of user interaction in the next upgrade is a sure-fire way to
prompt the customer to look around at the competition. After-all, users might
as well learn a brand new system.

Is change coming to Enterprise Software? I'd argue emphatically - Yes.
However, change is in measured movement, at a pace where users are not
overwhelmed. Conservatism is more valued than being on the cutting edge.

------
h0h0h0
Clifyt is the first comment on that article and I think he's got the right
take. Honestly there is a reason at times for what might feel like a bad
usability decision. I also didn't like the fact that enterprise software
usability decisions are paralleled with filing an expense report.

Seriously - it's NEVER a pleasure to do that.

37Signals.com - Why does childbirth have to be a pain?

------
r3570r3
Very well put. Enterprise Software fails to connect to the end user
drastically. They are never made keeping in mind the requirements of the end
user. The buyer poses with his/her requirements and this creates a lot of red
tape associated with the whole process.

------
jmount
The buyers were not the users when I last used BaseCamp.

~~~
mkramlich
The _creators_ were the users when Basecamp started out. They didn't want to
be forced to use shit, therefore their philosophy was to not make shit.

~~~
jmount
Last time I used BaseCamp it couldn't help with obvious things (like moving
all 3 parts of a 3 step project one day forward).

------
SandB0x
Remember: Nobody ever got fired for buying IBM.

------
jonknee
tl;dr steaks and strippers.

~~~
mkramlich
I've gotten the steak but never the stripper. Maybe I don't quite want
enterprise software to go away just yet.

