Blog

Expensive software sucks

May 15, 2012

While chuckling over Twitter with some friends about how all enterprise software is terrible, one of them replied:

"Which is weird, right? It's like if architects could only build cottages and skyscrapers always fell down."

It does seem like a strange contradiction. How could software be so unlike the construction industry? I found quite a number of articles about how awful enterprise software is, and I agree with all of them. But I don't think this is a coincidence of the vendors who make this software, or the industry, or the sectors. Instead, I claim that

expensive software is intrinsically likely to be of poor quality.

Let me walk through my claim by starting with some background:

How software is made

I've often thought making software is like building a house. (Because what do I know about houses.) Programmers use editors, construction workers use hammers. But a professor of mine once pointed out that it's really the wrong analogy. Programmers are designing software, much like an architect draws a blueprint. They're not making anything when they do this; you can't use software by itself, just like you can't move your furniture into a blueprint. It's a computer that turns the code into actions, just like a builder turns a blueprint into a house. So in a sense, programmers and architects are planning, but they're not making.

This dis-analogy is important because of cost. Most of the cost of a building is in, well, building it: hundreds of thousands of dollars even for a single building. But a computer can execute even very complex software for (usually) pennies. So while an architect and a programmer may get paid the same, one of them is 5% of the cost of the overall project, and the other is 95%.

The fact that software is mostly R&D cost and almost no manufacturing cost makes it very different from most of the products that other engineering traditions produce, like cars and furniture and skyscrapers. This matters because the cost to make just about anything (usually) sets a lower bound on its price. If it cost a lot to "manufacture" software, then a lot of the sale price would be set by the need to recover manufacturing costs for each item sold. But there's almost no per-unit cost for software, so the supply portion of the price is set almost entirely by its R&D costs. The more customers, the lower the per-unit cost needed to cover the fixed R&D costs.

Expensive software

I'll clarify that by "expensive" I mean "how much does the customer pay to get the software". If you buy QuickTime Pro from Apple, you pay $35. If you buy Photoshop, you pay $2000. If you buy an SAP installation, you pay ten million dollars. That's expensive. You could argue that SAP is not so expensive per user, because one $10M SAP installation serves hundreds of thousands of employees in an enterprise. I am expressly not accepting that definition of cost, and I'll explain why in a second.

Enterprise software is some of the most expensive software on Earth by this definition. There are lots of reasons for this, at least one of which is that enterprises (big companies) have a lot of money, and so it makes sense to charge them more because they have more to give. (This is what I like to call the "how much ya got" pricing model.)

But another force at work is simply recovering those development costs: a software package for huge companies costs a lot to make, and yet can only be sold to the few thousand companies on Earth big enough to need it. They each have to pay more in order to cover the development cost.

In contrast, cheap software is often cheap only because it has a lot of customers paying a bit each for it. That is: the R&D costs are not necessarily lower, it's just that the denominator of the cost over the large user base makes it seem cheap.

Software quality

Here are 3 quality data points:

QuickTime Pro installs in about a minute, and can load, play, change, and save movies.
Photoshop can do a lot with your photos, but not until you buy a book or take a class or frustrate yourself for hours deciphering its tools.
SAP can do literally nothing until you spend months customizing it with an army of consultants.

That's a pretty clean inverse correlation between cost and quality in my book. (Admittedly these are mostly comments on usability, which is only one axis of quality. But it is the axis that users typically care about the most, so it's not unfair to focus on it.)

What the market will bear

The software industry, like most others, mostly makes products that are absolutely as low quality as anyone will buy, and rarely higher. Speaking as an engineer I can assure you that the software you buy is of exceptionally poor quality compared to what is possible, and also compared to the engineering done in other commercial sectors. (My favorite restatement of this observation is this probably apocryphal quote from GM about what it would be like to own a car built like Microsoft Windows.)

It's not because software companies have poor QA practices, software developers lack training, and the discipline lacks rigor. These are all real problems, but they're symptoms of the root cause, which is simply that customers buy crappy software anyway. (A reductive explanation for why: new software is still being pioneered at such a high rate that most software companies feel that it is vastly more profitable to make new software than to improve old software. So whenever they can choose to improve quality vs. expanding the product to serve a new need or market, they usually choose expansion.)

By the way, I imagine that there is a distant future in which Moore's Law fails us, computing finishes saturating society, and the rate of discovering new ways for computers to help us dwindles. That will be a very well automated world, and in it the software developers of the day will finally turn, for the first time, to quality. But I wouldn't expect that to happen any time soon.

Complaint-driven quality

Which is not to say that software companies don't care about quality at all, it's just that they care about it as little as possible. And when you're trying to invest minimally in quality assurance, supporting your customers only when they complain is a good strategy. (Reacting to a complaint costs money, but not reacting to a complaint that doesn't exist is free. So there's a nice upside compared to hiring a testing staff who you have to pay even if everything is going well.)

Of course, there is risk in this reactive strategy: if you get lots of complaints, you'll spend a fortune on reactive quality measures like customer support, bug fixing, hot patching, deploying consultants. If you do too much support then you'll be forced to either react so much that it wipes out the sale price of the software, or else you'll have angry customers and they'll all stop buying your product. When this happens, I'd say "the market did not bear the quality of the software".

Per-customer support costs

Software companies can control the risk of being swamped with support calls by increasing the quality of their product--- if it works for you, then you won't need to complain about it. Here's an extreme example: Google search works pretty well, and you probably didn't learn to use it from a Google employee. Good thing, too, because when was the last time you called Google's 800 number to get help using search? Why, never, because there is no 800 number. Your zero dollars spent searching buys you very little personalized help from Google. This is not a coincidence.

But software companies don't have to (and therefore mostly won't) mitigate support costs beyond some profitable fraction of the per-customer purchase price of the software. Because see above: their goal is to care about quality as little as they can get away with--- as little as their customers ("the market") will let them. So how much support cost is justified by an Enterprise SAP installation with a ten million dollar price tag? Why, quite a lot! So much, in fact, that SAP and its affiliates can afford to send men in ties around the world in airplanes to make their customers happy with SAP.

If SAP is sending what are basically field engineers to each customer anyway, they know that it doesn't really have to work terribly well out-of-the-box. Polishing the base product would amount to little more than controlling support costs (an efficiency), which can only increase margins but can't increase top line. So instead, SAP will spend that effort on something with a much bigger upside: trying to increase the top line with new customers.

Happy customers, not happy users

Note that I said that these companies want to "make their customers happy". I did not say that they make their users happy, because they certainly don't. Their users are employees of the parent company, all busy writing scathing blog posts about how terrible the SAP software is. But they're not actually customers in the sense that they didn't write the check, and so SAP doesn't care as much if they're happy.

The "customer" is typically an executive, who, being rational, is perfectly willing to accept quite a lot of grumbling from his employees if the system basically works and is an improvement over what was there before, and justifies its costs. Compared to making millions of users happy, that's a low bar.

Few customers and high costs mean low quality

And here, finally, is my point: Enterprise software makes a small number of men ("customers") happy enough to write huge checks, without requiring the happiness of the much larger number of people who must use the software. The huge checks pad the enterprise vendor's support budget, which has a directly reductive effect on the vendor's quality efforts. Thus, the vendor's software will suck. I think that this low-quality effect is, because of the market incentives, intrinsic to anything sold at a high price to a small number of customers.

Just exactly like enterprise software always is.

Posted by rus at 12:36 AM

Comments