Why aren’t there more programming-language startups?

A few weeks ago, I moderated a panel where someone asked, “Why aren’t there more startups coming out of the programming languages community?”

This was at a panel about career paths, associated with the Programming Language Design and Implementation (PLDI) conference. What the person was asking was why we don’t see more cutting-edge programming language and software analysis technologies getting commercialized.

There’s clearly a lot of programmer pain. But why we don’t see more tech transfer of these “deep” technologies from research into industry is something I have been thinking about since I was in college, when I decided I wanted to spend my life making programmers’ lives better. Many other fields, from robotics to databases, have clearer paths to commercialization. But when it comes to new programming languages or software analyses, the path of tech transfer is often decades-long, if it exists at all. I thought about this as a programming languages PhD student, then as a professor, and now as the founder of Akita, an API-centric observability company based on applying software analysis techniques to API traffic.

But alas, I was just the moderator, so I had to focus on questions actually intended for the panelists. Last week, I did a Twitter thread answering this question. This post is an elaboration of that thread. I’ll talk about how, even though investment and buying for developer tools is on the rise, “deep tech” tools aren’t seeing their share of the growth. There are many things we can do to fix it—and I’d love to do that together.

The Tweet thread that led to this post.

In this post, I’ll focus on why we don’t see more high-growth startups focused on the kinds of languages and tools coming out of the PLDI community, the “deep tech” side of programming tools. There are many other kinds of developer tools that are doing great as high-growth startups. There are also other successful avenues of tech transfer (big companies; open-source projects) that I will not cover here.

Software teams are buying tools

There’s a popular narrative that companies don’t pay for developer tools (for instance see here), but this is decreasingly true. Even a few years ago, people were writing about the challenges for venture-backed dev tools companies and how it was hard to build big businesses around developer tools.

A popular point of view about developer tools buying.

By 2021, it’s generally agreed that there’s money in developer tools. Over the last few years, we watched Salesforce acquire Heroku for $212 million and Microsoft acquire GitHub for $7.5 billion. Today, the private company Postman is valued at $2 billion and HashiCorp is valued at $5.1 billion. Developer-first companies have also gone public and done well: the market cap of New Relic is over $4 billion; the market cap of Datadog is over $32 billion.

But what people aren’t shelling out the big bucks for is anything based on new programming languages and technologies, especially technologies focused around helping people write code with more guarantees. The entire static analysis market size in 2020 is estimated at $748.1 million in 2020 and is projected to reach only $2002 million by 2027. And programming languages development largely happens supported by big companies, as in the case of Go and Python, or by enterprising language developers who find some other way to support themselves as they corral their open-source communities, as in the case of Ruby, Elm, and Julia.

There’s clearly programmer pain—and pain that some of these new languages and tools could solve. What gives?

But programmers are voting with their budgets

Could it be that engineering leaders are choosing tools against the wishes of their developers? This is what many people say (for instance, see here).

A common question about developer tools buying.

But the data doesn’t support this. According to the State of the Developer Nation in 2017 (via SlashData), 77% of developers now have a say in tool selection. And they’re choosing to spend that tool budget on products that make their work lives easier, rather than tools that make their code higher quality. For better or for worse, these two concerns are not the same.

Graphic from the SlashData blog.

It’s worth calling out the difference between programmer aspirations and programmer needs. I would love to have an aviary in my backyard and where I can keep pet owls. 🦉 But what I need to do right now is write some emails and eat lunch. Similarly, programmers would love to ship bug-free code on time that always runs as fast as it did in test. But what they need is to fix their hair-on-fire incidents, then make up time on the roadmap so they can get their scheduled features out the door ASAP. The eyes of a software developer may widen at the mention of a tool that can magically reduce their bugs to zero, but a software developer grounded in reality knows that the truth is their users seem to have quite a high tolerance for certain bugs. A software developer might use that nice shiny research language to blow off steam on weekends, but they know in their heart of hearts that adopting it in their messy work code base isn’t the best way to advance their career.

So why are developers choosing to spend money on certain tools and not others?

Working developers aren’t buying “luxury goods”

Some will say that it’s just a matter of time before we see adoption of the fancier, deep-tech stuff. My two cents: the programming languages community currently holds some assumptions that are at odds with programmer needs.

Here are a few programmer needs that don’t fit with the PL worldview:

  • Zero bugs: usually not the top priority. A common goal in language design and software analysis is “soundness:” if there is a bug, the tool will find it. If you’re building a spaceship where a single bug means that you lose lives and millions of dollars, it makes sense to go through possible bugs with a fine-toothed comb. For the average web app, however, there’s a big tradeoff between fixing bugs and shipping features. Web app developers often need something that helps them build software quickly, without sacrificing too much correctness—not the other way around.
  • People don’t want to know about all of their problems. I often see “fancy” techniques assume developers want to know about everything that’s wrong with a system. Is your friend who always tells you everything that could go wrong your most popular friend? People don’t want to know all of their problems, especially when not all of the problems matter. If you want to make developers happy, give them a prioritized list of what to do next, not an overwhelming list of potential issues that will make them mute your notifications.
  • Tech stacks are organically evolving ecosystems, not centrally planned entities. Now for the question of why no single programming language or framework is going to take over. Just as it’s appealing to dream of silver-bullet solutions in any other domain, it’s fun to dream about The One True Language. But most systems of a certain maturity pick up a second language, then a third. Different layers of the tech stack pick up their own languages and technologies. This isn’t because organizations are disorganized, or haven’t thought things through. Languages evolve, the needs of a system evolve, and the next generation of programmers evolves.

From the point of view of working developers, the idea of zero bugs, having the kind of timeline that lets you address all bugs, and having complete control over the tech stack can seem like impossible luxuries.

The techniques that the programming languages community have been developing aren’t broken, but they need to adapt to the needs of working developers! In the next section, I’ll talk about how. (And if you’re curious about how learning about this led us to pivot what Akita does, we talk about it more in this blog post.)

Tools need to fit into developers’ everyday lives

In order to fit into developers’ lives, programming tool creators need to work backwards from the intended developer experience, rather than forwards from the technology we want to build. And in order to do this, we’ll need to engage a discipline that’s often considered a dirty word among technical people: design.

I often see programming tools people ignore design, but I believe it’s because of a misunderstanding about what design is. Especially in programming tools, design means reducing friction to help developers get to where they need to go, not increasing prettiness or dialing up the trappings of good user experience, like cute error messages or dark mode.

Here are a few lessons I learned from doing user research and working with designers, that could help package existing technologies in a way that’s directly helpful to developers in their jobs:

  • The problem that the tool is solving matters more than anything else. In technical programming languages communi

Read More

News Bot

Published by
News Bot

Recent Posts

Japan pitches ‘Society 5.0’ to keep its edge in tech and science

TOKYO -- Japan is showcasing its latest scientific achievements, ranging from sea and air to…

1 hour ago

Tether executives said to face criminal probe into bank fraud

We've detected unusual activity from your computer network To continue, please click the

1 hour ago

BLAKE3 1.0

version 1.0.0 Changes since 0.3.8: Add Hash::from_hex() and implement FromStr for Hash. Implement Display for…

1 hour ago

Why does NBC make it so difficult to watch the Olympics?

I’ve noticed a lot of ads about the Olympics over the last week. Apparently the…

1 hour ago

A 3-quart Instant Pot Duo Nova is just $50, down to the lowest price we’ve seen

Summer 2021 already feels like one of the hottest ever, and turning on the stovetop…

1 hour ago