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.

To my utter surprise there were good reasons for why 9 of my items worked the way they did. And some of them were things like it actually being a law that you had to explicity retype a student's identification code.

The problem with enterprise software, is less often the software, and more often the enterprise. I've seen expense reports that have had to go through 6 organizations, each with slightly different ways of handling various parts (some handle things for tax purposes, others of SarbOx, others for fraud detection, etc...). It's not as easy as an iPad sketch program.

And laws are the enemy, I tell you :P (and the local equivalent of the IRS, and other regulatory organizations, and... you get the idea).

Not to mention the UX isn't a high priority requiremente (I've been asking for UX help since I joined the company, I do what I can but it's not the same)

For example: European regulations on data retention and local law means we have to ask for some billing information each time, an anti-terrorist law means we have to ask some really stupid information on every single form, IRS-equivalent regulation means we have to follow some archaic accounting practices, legal requirements mean that many documents which could have been happily emailed or otherwise electronically handled have to be faxed, etc, etc, etc ad infinitum

Should the sales users override the financial users, or should purchasing have the final say?

Maybe it sucks because the buyer is not the user, but maybe it also sucks because it tries to solve awkward problems. Everything is relative. It doesn't try to be simple, but there is a market for complex software, like it or not.

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

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.

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.

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.

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.

    * 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

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...

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".

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.

I've worked in a few Fortune 100 organisations, and I've got to say that enterprise software doesn't tend to solve hard problems: financial reporting, workflow support, resource planning, HR aren't inherently hard.

What is hard, is selling them into big organisations, commitment of the management hierarchy, deployment into the processes and sometimes forcing end-users to deoptimalise their results. This all costs huge dollar figures, and the organisations need to sell that internally and come up with suitably vast business cases.

Maybe I'm being a tad cynical here, but I have participated in the process several times after being informed that a cheaper, more appropriate solution for these "enterprise needs" couldn't get buy-in - and in enough big 100k+ enterprises that it's not just unlucky happenstance.

Most of the software that solves big, hard problems are domain-specific, not really enterprise software. They are deployed for point- or black box solutions for the business: things like industrial process control, tax/logistics montecarlo tradeoff analysis, MPLS tag path provisioning, factory and warehouse logistics optimisation, geophysical seismic analysis for hydrocarbon prospecting, etc etc.

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.

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.

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

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).

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.

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.

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.

11) COTS enterprise software, as often as not, is a Frankenstein mismatch of packages purchased by the vendor and stitched together. Our major software system is on its third owner. We have access to the source code. It dates back 20 years to mainframe software that has been ported. It's written in a combination of COBOL, C, PL/SQL, Java, Oracle Forms, and a smattering of browser scripting languages. The vendor's software suite is completely purchased and thrown together (a.k.a integrated) in the cheapest way possible.

12) Developers of enterprise software often get requirements from a dedicated analyst. Perhaps it was me but when I tried working from another person's analysis, I found it hard producing software the users actually wanted.

13) Software developers are not interface/user experience designers. Enterprise software vendors hire many more of the former than the latter.

I'm not a fan of having the analyst role split out from the development role. Coming to understand the user requirements is a major part of development. Requirements are not facts to be memorized and worked through like a check list. They have to be internalized to the point that you understand why something is a requirement.

Much the same argument as with the analyst role. I would rather have a developer with a passion for UI design get the proper education in design instead of having a developer and a designer as separate people. My experience is that some developers naturally gravitate towards the visuals, so harness it.

EDIT: Removed footnote marks because they looked confusing.

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.

One reason a lot of enterprise software gets bloated is that, in order for the market to be viable, it's hard to just target a single niche, so you end up with a superset of features so that you can sell the same market to customers with different requirements.

Even in the best case, though, system specialization can be a knife-edge that cuts both ways. Many of our customers, for example, are in a trouble precisely because they have way, way too many one-off systems. They have this system over here that does just workers comp claims, and another system for handling personal auto claims, and another system for tracking notes, and an entirely different system for first notice of less entry versus for actually handling claims, and then most of their commercial business is in yet another system, except for some specialty lines that are elsehwere. Then they have five different policy administration systems, and a couple of billing systems, and each of those talks to a different document production system . . . it's a total nightmare.

So sometimes the choice is between having 3 complex systems or 25 purpose-built systems and a total integration and user training nightmare, and both options suck.

Basically, as soon as you have a bunch of data that you need to do a ton of different things with, you're left with two bad choices: you can create one really complex application that tries to do everything, or you can create a bunch of smaller applications and end up with a bunch of complicated integrations. Fundamentally, as soon as you have complex data that you have to do a bunch of stuff with, you're going to be in trouble no matter what you do.

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

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.

http://lists.canonical.org/pipermail/kragen-tol/2005-April/0...

http://37signals.com/svn/archives2/define_enterprise_in_10_w...

To give one easy example, I personally was doing Agile and Refactoring and Design Patterns looooong before a popular term for them swept the industry and the fads came. And lots of folks were running automated software tests before the Unit Testing (tm) fashion began -- even if they were in the minority, not the mainstream. And I'm sure I wasn't the only one.

In the case of 37Signals and enterprise software, I'm sure there were at least hundreds and perhaps thousands of people before who both used that sort of software and independently had their own theories as to why it sucked. The whole "captured audience" element and "afraid to declare a project a failure for fear of losing job" were pretty obvious, I'm sure, at least as far back as the 80's (that I can confirm personally anyway.)

I saw this kind of template for so-called "discoveries" and "innovation" so much that I coined my own private term for it, "Discovering the Obvious" or DTO.

So what I'm saying is, citing an article from 2005 where somebody made a similar set of observations/predictions about enterprise software does not invalidate or lessen the value of what somebody else said in 2007. Nobody owns ideas: they're often independently arrived it in parallel by widely dispersed groups, and can even disappear and reappear in a culture, in cycles, over time.

Heck, the bookstore is full of books written or published in just 2010 where the authors share earth-shattering new secrets about love and life that arguably have been well-covered in tons of books that came out in past decades if not centuries and were even known as far back as that ancient uncivilized barbarian Will Shakespeare.

But thanks for the link! :)

Too much caffeine today.

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

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.

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.

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.

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

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