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.
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.
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.
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?
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).
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.
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?
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:
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.)
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:
TOKYO -- Japan is showcasing its latest scientific achievements, ranging from sea and air to…
Click here to close this panel.
We've detected unusual activity from your computer network To continue, please click the
I’ve noticed a lot of ads about the Olympics over the last week. Apparently the…
Summer 2021 already feels like one of the hottest ever, and turning on the stovetop…