The Inverted Lemon
It isn't the customer who is left with a bitter taste in their mouth...
The lemon market was first described by economist George Akerlof in his seminal paper: “The Market for ‘Lemons’.” That paper won him the Nobel Prize in economics.
It has often been argued that software is a lemon market. In particular, Schneier made this point about security software in this article. The same argument has been applied not only to software security but to certain facets of software quality; such as, maintainability and testability. In this essay, when I’m talking about quality I’m really talking about these two facets of software quality.
The argument goes that Software is a lemon market because the people buying software do not have the skill nor the information to judge whether a given piece of software is high quality or not. As such, quality does not really impact their decision to buy the software at all.
However, the interaction between quality and price is much more complicated than it looks. I am going to argue that software is a lemon market but not in the traditional way. The suckers are not the customers, it’s the companies that make low quality products.
What is software quality anyway?
I think of software quality as a list of “ilities” and while the list of which ones are priorities changes from application to application:
- Security
- Maintainability
- Testability
- Performance
- Portability
- Usability
I don’t want you to get too hung up on the order of this list. Different projects will weight these attributes according to their requirements. However, what is interesting is that the end user is only interested in a few of these attributes.
- Usability
- Performance
- Security
- Portability
Testability and maintainability are gone. They don’t even exist for a user of the software. Your code could be world-beatingly beautiful or it could be a giant ball of suck, they don’t care. Worse still, on first examination the customer won’t pay you a dime more either way.
As long as you put a shiny, sensible interface over that ball of mud, it’s all good.
Why software is not like a car
The main theme behind the idea of the lemon market is that the asymmetry between buyer and seller in information about the cars leads to a situation where the buyer has no way to accurately gauge the quality of what they’re buying.
The example that most people can relate to is the buying of a used car. The idea being that vendor usually has much better information than the buyer. This results in people getting ripped off, which if left unchecked, could result in a total break down of that market.
However, it is misleading to try and apply this definition directly to software. The problem with the car analogy is that physical items under go wear and tear. A piece of software will be the same quality on the day it was published to the day it finally falls out of use, provided no updates are made to it. In short, code doesn’t rust.
If a user buys a low quality program, it is not a lemon in the same way that a car that barely works is. A poor quality car will randomly and expensively fail in various areas after purchase. A poor quality program may fail expensively but it will fail in precisely the same way every time.
The none-rusting property of code changes the quality calculation considerably. If software doesn’t rust then the quality just has to be good enough. Good enough is simply a case of ensuring there are no show-stopper bugs; good enough is a synonym for “barely works.”
This idea of “barely works” is an anathema to most software developers. Good developers are unhappy writing anything but the cleanest code they can possibly write. If Barely Works were a developer we’d stick it the stocks and throw rotten fruit at it.
But developers have a distorted view of the software. It’s completely different to the view of a paying customer. Developers see all the bugs in the bug tracking database. Developers see all the suck in the code. Developers see all the poor architectural decisions and secretly think of ways to fix them.
The users see a reasonably good interface and only the bugs that stop them working.
Therefore, by simply fixing the bugs the users see, you can improve the impression of quality without doing a lot of work. As such, “barely works” makes a great deal of business sense.
In some cases, like the recent MySQL release, even shower-stopper bugs do not hold back a release.
Hold on a second, I thought that it is cheaper to write quality software?
Technical debt is a wonderful expression because it is succinctly explains to a laymen the insidious invisible cost of bad design. Unfortunately, the concept of technical debt also explains why convincing people to pay off that debt is a tough sell.
The problem is that the interest rate on technical debt is very small. The interest rate can’t be any greater than five percent. In fact, it’s probably a tenth of that value. As such, you can build up truly gargantuan amounts of technical debt and the cost of servicing that debt is tiny in comparison to the size of the principal. So why not just have an interest only mortgage and never pay back the principle?
It does seem futile, doesn’t it? Say you kick off your project to pay back that giant debt, for the first few months you’re going to be paying off nothing but interest and you won’t make any appreciable dent on the principal. You’re basically going to be thrashing around doing a lot of work and not achieving a great deal.
With most business applications, making the code base testable at all is a major multi-month project. It’s a risky project too; you risk breaking a lot of working code without adding anything the business can see as an improvement.
If you eventually manage to pay off your technical debt and you keep it paid off then, yes, it will be cheaper overall to write quality software. The problem though is that getting there in the first place.
If getting to the promised land requires scaling Mount Everest without bottled oxygen, don’t be surprised if you don’t have many takers.
Inverting the Lemon
So far I’ve made the argument that quality, in the sense of maintainability and testability, doesn’t matter. This is because the average user has no way to choose between a program consisting of a single gigantic main method and a program that is designed sensibly.
However, that is not the whole story. There are places in the industry where quality matters. Barely Works is not going to be acceptable in pace-maker software or missile control systems.
Even in general business software, there are some companies that have made quality their power-animal. The reason why quality works as a business strategy for them is because their audience understands that they’re paying for quality. That’s the point of their brand.
Take bugger trackers for example. Fogbugz is arguably the best bug tracker in the world. Everyone who buys Fogbugz knows they could just install Bugzilla but they don’t. The reason they don’t is that Fogbugz sucks less in pretty much every dimension.
If software really were a lemon market, Fogcreek would have gone bust years ago. In fact, if you look at every single one of Fogcreek’s products, there is a mature open source competitor that they totally spank.
You see, the people who want quality will pay for it. Moreover, the people who demand quality know what they’re looking for - they’re informed buyers.
So few people develop quality software that the people who do can charge above the market rate for their product. Therefore, while it may be cheaper to develop high quality software it ends up being more expensive to buy. This makes it far more profitable to develop quality software!
Most software companies have got such a huge principal on their technical debt that trying to convert their business to a higher quality and thus more profitable outfit would put them out of business. This is the economic barrier that keeps quality software a niche.
And that, my friends, is the inverted lemon. The joke is not on the end user, they got exactly what they paid for, the joke is on the business who pays through the nose to maintain a crappy product - and they make less money selling that product while they’re at it.