Why Enterprise Software Sucks(37signals.com)
37signals.com
Why Enterprise Software Sucks
http://37signals.com/svn/posts/669-why-enterprise-software-sucks
27 comments
This is exactly right. I actually was a user of enterprise software at the university and put together a list of my complaints about the software. Probably a list of ten items.
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.
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.
I currently develop and maintain "enterprise software" for a large insurance corp.
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
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
Yes. If you are looking to buy an ERP system to cover your South Korean, New Zealand, and Norwegian sales operations (as well as North America and your small but growing and complex Vietnamese operation) including support for all local tax laws, currencies, and languages (including double-byte right-to-left screen layouts), then how would you choose which of the users should make the buying decision? A vote?
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.
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 didn't dig deep enough on this one.
Jason Fried didn't author this article. It's credited to Zubair Hamed.
Jason Fried didn't author this article. It's credited to Zubair Hamed.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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...
* 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...
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".
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".
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.
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.
On the other hand, complexity also geometrically increase the payoff for successfully making intuitive software.
in some markets
I personally doubt the big, hard problems in enterprise 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.
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.
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.
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.
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.
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.
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.
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?
The more interesting question to ask is - are we solving the right problems?
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).
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).
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.
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.
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.
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.
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.
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.
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.
Fantastic list but just to add a few items from my experience.
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.
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.
#7: Exactly. There is no 80-20 rule for enterprise software. If you don't meet 100% of the requirements, it isn't a replacement for their current system. You can't compromise on functionality for the sake of usability or elegance; every item on the spec sheet has to be included.
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.
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.
Yeah, you definitely have a point there. While many problems have a high degree of inherent complexity, there are plenty of others that don't need to and that have features bolted on left and right to appeal to every possible market. And it's definitely true that big companies hate making these sorts of decisions, because it's expensive and time-consuming and difficult to undo.
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.
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.
Integrating a whole bunch of small, well-designed tools is just as expensive and time consuming. And the final results are often worse.
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.
Another very common case is that the app is in maintenance mode; only legally required changes are being made. There's no money to do a UI rewrite for an internal app, especially in the "current business climate".
I have a few observations to add based on my own experience as well.
Due to the fact that most enterprise software is developed by those not qualified to get better jobs, a lot of enterprise software is complex due to bad engineering. The really aren't very many business requirements that are, by themselves, complicated. The complexity comes from a foolish and pointless attempt to deal with all of them at once by developing a framework rather than an application. The sorts of developers that work in enterprises tend to be the sort that don't realize that they're abusing the classic software anti-patterns and making things far worse.
Another problem is due to who makes the decisions about what to buy and what the requirements for in-house software are. It's rarely someone who has any connection to the solution, but rather a manager or executive with an agenda, which occasionally has some relation to the software's purpose, but more often has to do with brown-nosing.
One example is Visual J++. At one point, Microsoft had gotten Visual J++ into something like 70% of Java development shops in the US. They did this by marketing directly to clueless executives who didn't know the first thing about whether or not it was suitable to the task at hand, rather than to the developers who were in reality using a standard Java JDK and a free (or cheap, back then there were several of both available) IDE instead.
Due to the fact that most enterprise software is developed by those not qualified to get better jobs, a lot of enterprise software is complex due to bad engineering. The really aren't very many business requirements that are, by themselves, complicated. The complexity comes from a foolish and pointless attempt to deal with all of them at once by developing a framework rather than an application. The sorts of developers that work in enterprises tend to be the sort that don't realize that they're abusing the classic software anti-patterns and making things far worse.
Another problem is due to who makes the decisions about what to buy and what the requirements for in-house software are. It's rarely someone who has any connection to the solution, but rather a manager or executive with an agenda, which occasionally has some relation to the software's purpose, but more often has to do with brown-nosing.
One example is Visual J++. At one point, Microsoft had gotten Visual J++ into something like 70% of Java development shops in the US. They did this by marketing directly to clueless executives who didn't know the first thing about whether or not it was suitable to the task at hand, rather than to the developers who were in reality using a standard Java JDK and a free (or cheap, back then there were several of both available) IDE instead.
read my mind, awesome list.
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.
The money just doesn't exist to obsess over UI in these products.
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.
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.
You still need to spend a lot of money on lawyers and accountants to get the local and international laws correct.
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/0...
Many supposedly new ideas are not "original," I think. There is often just 1 person, or a few, who might publicly proclaim it or document it in such a way that it becomes widely disseminated, accepted or believed. Or one person who takes 5 old ideas and smooshes them together in one particular new mashup.
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.
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.
That's a massively superior article, but what makes you think that Jason read that?
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_w...
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
http://news.ycombinator.com/item?id=72115
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.
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.
[deleted]
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.
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.
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?
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.
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.
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?
Seriously - it's NEVER a pleasure to do that.
37Signals.com - Why does childbirth have to be a pain?
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.
[deleted]
The buyers were not the users when I last used BaseCamp.
Remember: Nobody ever got fired for buying IBM.
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.