page updated on August 24, 2017

What if Programming Language Adoption is a Lemon Market?

A 1970 paper called The Market for Lemons (PDF link) discusses an economic concept called information asymmetry. Whereas simplified and classical economics suggest that buyers and sellers have perfect and complete information, so that the market works with perfect efficiency to find the right price and to match buyers and sellers, information asymmetry tries to be more realistic. In some circumstances, a buyer may know much more than a seller (or vice versa), so that one party in the transaction may have a huge advantage over the other.

The Lemon Market for Used Cars

The Lemon Market paper uses the example of used car sales to demonstrate this principle in practice. Assume that most buyers of used cars have neither the knowledge or the resources to examine a car for the kinds of flaws which can make buying the car a poor economic decision in the long run. Buyers know this, and set their price expectations accordingly. This pushes down the expected sale price of all used cars; there's little reason to assume that a car in an unknown condition offered by an unknown buyer has greater quality than average. Thus the price must reflect the uncertainty of a catastrophic outcome.

Put another way, if there's a 10% chance that Car A may fall apart the minute your check clears and a 50% chance that Car B will do the same, the price of Car B will necessarily be discounted greater than the price of Car A.

Of course, sellers know that buyers have put the expectation of risk in their prices. A potential seller likely knows the quality and risk of a car and may decide in fact not to sell it if the quality of the car exceeds the value he or she might receive for selling it. In other words, there's little economic value to a seller with a car above what the market expects from a used car.

This is where the problem really starts. If enough potential sellers refuse to sell cars of above average quality, the average quality of the cars available for sale will plummet. Then buyer expectations will decrease and more sellers will leave the market.

At some point a model will reach equilibrium, but you can see how this information asymmetry is bad for the market as a whole even as it allows specific actors within this model to exploit other actors.

The Market of Programming Langauge Adoption

Many economists and thinkers have applied the principle of information asymmetry to their analyses of various markets. The similarities to and differences computer programming are instructive, especially when considering the adoption of programming languages.

Choosing a programming language is like buying a used car because you can't have complete information about how the language will meet your needs until it's either helped your project succeed or held back the project with failure. Choosing a programming language means guessing at the answers to questions like:

• Can we recruit or train the right number of programmers at the right skill level within our budget near our preferred locations?
• Are the necessary libraries for the language of sufficient quality and maturity? If not, how difficult will it be to create and support our own?
• What will it cost to deploy and maintain software written in this language?
• What kinds of tools and utilities are available in the ecosystem around the language and the software written in the language?
• What does the language make easy? What does it make difficult? What does it make possible? What does it make impossible?
• Does the language impose any limitations we haven't already accepted?
• How does the language fit into our current technology stack?

Programmers are bad at answering these questions. Programmers are bad at acknowledging—let alone analyzing—business concerns. Don't expect vendors from Microsoft, Oracle, or enterprise technology consulting companies like IBM or Accenture or SAP to answer these questions for you either.

Keep in mind two things. First, any language supported by a large company has marketing and sales departments more interested in selling you tools and support and consulting services than in solving your business's problems and reducing the risks of using that language. Second, any language without a sales or marketing department is probably supported primarily by programmers, and they're more interested in cool features and theoretical purity and grinding whichever technological axes they prefer than figuring out what's best for your business.

Besides that, only you know the risks and rewards that apply to your business.

Cars are Commodities and Programming Languages are Not

The analogy between a Lemon Market for used cars and a Lemon Market for programming languages breaks down in one important way. A car is a commodity. Ideally, any two cars of the same model year should be roughly comparable. A car with a good service record is less risky than a car with a poor service record. A car with low mileage is probably in better shape than a car with high mileage.

One programming language may be similar to another. In fact, many programming languages are easy to group into families with similar characteristics. Yet a programming language is more like a toolbox for solving problems than it is a car for carrying people or groceries or a child soccer team from Point A to Point B.

In other words, two cars of similar vintage and age are roughly equivalent in terms of Lemon risk, while two programming languages may be similar in broad scope butvery dissimilar in terms of risk to your business.

Risks of Programming Language Adoption

The risks of adopting a programming language are that you may discover it doesn't meet your business's needs. The riskier risk is that your business's needs will change. Perhaps success means that you need more features sooner, but you can't hire or train enough good developers. Perhaps success means that you need better performance than you anticipated, and now you're facing a significant rewrite of portions of your product. Perhaps success means that you've moved up to a higher tier on your support plan and have to pay your vendor millions of dollars you didn't anticipate.

As you might have noticed, a lot of these risks are actually business risks—not risks endemic to the technology. Some programming languages are riskier than others, but in many cases, the plausible candidates for the type of problem you want to solve are roughly equivalent, at least until you reach various milestones of success.

Poor Strategies of Managing Risk of Programming Language Adoption

You may have noticed the marketing campaigns behind enterprise programming languages, libraries, tools, and ecosystems attempt to address adoption risks. "No one ever got fired for buying IBM," people used to say. "The world's biggest companies run Oracle," some people say. "Everyone in our office knows Microsoft," you might hear.

Those slogans don't answer the questions you really need to answer. "How does this programming language help us meet our short term needs? How does this programming language help or hurt us in the medium term? In the long term?"

A big company behind a programming language will sell you support contracts and libraries and consultant hours and tools, but it won't write your software for you. It won't wave a magic wand and solve your problems, unless your problems are solely "We have too much money."

A community of free software developers and small consulting companies or a non-profit supporting a programming language may sell you smaller support contracts and will probably write some generic code for you and share it with everyone else, but that community still won't write all of your code for you. It's only a little more obvious that that community doesn't have a magic wand (but if you engage that community on its own terms, you'll probably discover that everyone has similar problems and you have options for solutions).

You cannot reduce the risk of adopting a programming language by basing your adoption on the notion that a support contract will reduce your risk, because no support contract will address the interesting business risks you face.

The Lemon Market of Programming Language Buzz

You also cannot reduce the risk of adopting a programming language by basing your adoption on the notion of what's popular or what has buzz. How do you even measure that? Yet that's what the Internet wants you to do. The inevitable and ubiquitous mentality that makes everything into a horse race with a single winner means that the Internet is full of comparisons of buzz and marketing gslogans and silly measurements that have as much to do with the applicability of a technology to your business goals as the apparent position of the sun in zodiac symbol at the moment of your birth has to do with where you're going to live, who you're going to marry, and your current salary.

Yet you can see a market asymmetry at work. It's not necessarily between buyers and sellers. It's between the users of a technology and the language. It's between programmers, business users, and the programming languages.

If programmers know that buzz helps business users decide which language to use and the choice of language dictates which programmers can get hired, programmers will tend to gravitate toward languages with buzz.

This cycle reinforces itself in two ways. First, it speaks toward the real risk of being able to hire enough developers. (It doesn't necessarily address hiring the right developers at the appropriate level of quality and experience, but too few companies go that far anyhow.) Second, it raises the risk of hiring developers and using that language with a buzz, because it reduces the amount of experience the average hireable developer has with that language. The number of developers may go up, but the percentage of developers with a deep understanding of the strengths and weaknesses of the language has gone down.

Your risk of hiring someone without the deep experience to help you navigate the short and medium and long term business needs goes up.

Worse yet, when buzz happens to an immature technology, the quality of code and deep knowledge of that tool suffers. Programmers tend to love shiny new things. It's a character flaw. Many programmers flit from language to language as they are new and shiny but leave as soon as it gets too mainstream. Rather than having ten years of experience learning something well, these programmers have one year of experience learning something new repeated ten times.

In their wake, these programmers leave swaths of half-finished libraries, tools and techniques adopted from other languages and shoehorned into new systems, and loads of code that'll have to be redesigned and rewritten to meet business needs. If the world is fortunate, the technology world will have learned a lot about what will (and mostly what won't) work, so that subsequent users of that language will avoid the most obvious flaws.

Of course, by that time, the Lemon Market of Programming Language Buzz will have moved people on to another language, where the quality of developers and tools and techniques will go down.

There is an irony, of course. Programming languages without buzz (whether that buzz has come and gone or whether it's never arrived at all) may have a higher quality of developers. In the case of community-developed programming languages, the early adopters tend to be the best developers. Either they've developed the language for their own specific needs or they seek out and study new languages despite a lack of buzz to add to their toolkits and improve their knowledge of programming in general. If you can hire before the buzz, you're likely to get very high quality programmers.

The Asymmetry of Programming Language Adoption

Unlike the used car market, developers and businesses and programming languages aren't on the opposite sides of a single transaction when it comes to language adoption. On the other hand, a programming language's community or commercial entity may decide to avoid a market or niche because of a perceived lack of value. The value of a market or niche isn't solely determined by the hiring decisions of businesses based on the buzz around a language, but you can see that the buzz around a language such as PHP as "being really easy to set up a web page" has drawn in enough developers of such low quality that you can hire web developers for minimal pay to write awful software—and you'll have a very difficult time hiring great PHP developers in that situation, because they're rare in the large pool of cheap PHP developers and they're not willing to work for minimum wage. Similarly the glut of inexpensive developers from the Indian subcontinent churned out of Java and C# schools makes those languages seem less risky (if you view developers as cheap, fungible cogs). Computer programming and software development is an art as much as it is a science; ask any software engineer to throw something together as cheaply as possible and you'll get a confused look, at best.

No, the asymmetry is this: when choosing a language to adopt, you won't know how well it addresses your business needs until after you've adopted it. You already know this for the programming languages you already use. You have asymmetric knowledge, and this makes it difficult for you to judge the risk. (Of course, this applies to all software you haven't written yet. It's the nature of software; you don't know how to write it until after you've written it.)

If you're truly an enlightened businessperson or technologist, you might find a programming language without buzz but with the maturity of great libraries, tools, and developers. Sure, you'll pay a little more than you would for a small army of PHP-wielding teenagers or offshored Java or C# coders in a far-flung time zone. Yet in return, you just might find that you'll get developers with a deep understanding of the strengths and weaknesses of a technology, who understand the tools and ecosystem, and who are motivated by something other than chasing the latest fad.

If you're truly an enlightened technologist, you've already realized that technical superiority (perceive or otherwise) is never the sole determinant of market success. Solving real problems in predictable ways is more important. Addressing business risk sensibly is more important. Writing and maintaining and deploying software sustainably is more important. Chasing buzz for the sake of chasing buzz—and advising businesspeople to chase buzz with you—adds an asymmetry into the programming language market, and that's only good for those people who refuse to play this game, because they're going to win while you're competing yourself out of competition.

In other words, when you find yourself asking "How little can I spend on custom software development" and typing hire PHP developers or cheap offshore software development into Google, you're making the market worse for anyone interested in custom software development. Good software development services have little incentive to chase dollars from cheap customers, and effective software development companies are more interested in providing high quality at good prices than dealing with customers arguing over every penny spent.