It's time to build developer tools

It's time to build developer tools · 2020.12.29

We are living through a golden age in developer tools.

Every company is now a software company.

Every software company needs developers—and developer tools.

The ecosystem of companies building tools for developers is booming. If you are a developer who loves the art and craft of programming, if you like working on technical problems beyond scaling CRUD, or if you love the idea of accelerating technological progress by building tools for people like yourself, you should think about working on dev tools!

Historic forces, immense opportunity

Every company that now writes code has discovered (or is discovering) that software development is really tricky. The world needs more software, but it’s not as simple as hiring more developers. Building software doesn’t scale or parallelize easily. Serial dependencies coupled with unforeseen complexity lead to gross underestimates of timeline and budget, which in turn lead to bad business outcomes and even existential crises.

To address the challenges of developing software quickly and efficiently at scale, more and more companies are building and buying developer tools. It’s no longer just the Googles, Facebooks, Microsofts, and Amazons of the world spending serious money doing so.

To satisfy this increasingly apparent need, a rapidly growing new industry of developer tool companies has arisen in recent years. Individual names like GitHub, GitLab, and HashiCorp are now well known and the emergence of the field has not gone unnoticed.

It’s difficult to overstate how quickly the market for developer tools has grown in the past decade. When Quinn and I started Sourcegraph back in 2013, we quickly discovered that “dev tool” was a dirty word among investors. Developer tools, it was thought, were super valuable, but most of them were single player tools that didn’t make enough money (e.g., JetBrains, Sublime Text), internal tools built for the specific needs of a particular big tech company (e.g., Google Code Search), or open-source projects that no one paid for and which you could only make money from by selling services and support. Investors told us there was just one billion-dollar company that sold to developers—Red Hat—and it was the exception that proved the rule.

Developers were building lots of valuable software that was sold to other folks—salespeople, marketers, designers, etc.—but when it came to their own work, the common refrain was, “the cobbler’s children have no shoes”. An article in TechCrunch lamented, “Will Developer Tools Startups Ever Find Investors?"

But then, somewhere along the line of the past seven years, something changed. Evidence of this shift is in the valuations: GitHub acquired by Microsoft for $7.5 billion, GitLab valued at $6 billion, HashiCorp at $5 billion, JetBrains estimated at $7 billion, the list goes on.

But though the big numbers with lots of zeroes raise eyebrows and make the headlines, they are just the byproduct of the underlying factors driving big changes in where and how software is built. To list a few of these:

Big Tech: Competition from Big Tech and tech-enabled startups moving into every industry is driving every company to prioritize software as a core competency.
Big Code: The amount of code in the world has been growing rapidly, and more and more companies have reached a tipping point previously reached only by the largest tech companies.
Enterprise OSS: The maturation of “the cloud” as a software platform built on top of open-source software (Linux and Kubernetes), in contrast to older software platforms, which were vertically integrated proprietary ecosystems (e.g., Windows + .NET + Visual Studio).

There are many other trends at play here, but one thing is certain: almost every valuable or growing company is now building software and most have realized they need great developer tools to compete.

This is fantastic news. “Tech” has traditionally been a distinct sector of the economy, and the ability to build software effectively at scale was confined to a handful of big technology companies. Now, companies in every sector understand that code has to become a core part of their DNA. And this means the impact of code and software is amplified. No longer does the value proposition of software have to flow through some product or service offered by a “tech company”—companies across every sector of the economy are now learning how to build great software themselves.

As the broader economy learns to build software, progress will accelerate. All the promises that the future holds—cures for cancer, life-saving medicine, mass individualized transportation, rocketships, and more—will arrive sooner in large part thanks to code. Software has long been recognized as a technological accelerant. But developer tools are now a second-order accelerant on technological progress. This is an immense opportunity.

How best to pursue it?

Large companies, open source, and startups

There are three places where you can work on developer tools. (There may be more, but for brevity’s sake, we’ll focus on these.)

The first is inside a large non-developer-tool company. Many large companies that build software are investing heavily in internal tools. There have been a lot of great dev tools created inside large companies, and many such tools have inspired the creation of similar tools outside the company. Blaze, the build system of Google, inspired other build systems like Pants and Facebook’s Buck and was later itself open-sourced as Bazel. Large companies also offer the benefit of a large, stable salary. The downside is that the direct impact of your work will likely be limited to a single organization. It’s possible that your work will be open-sourced down the road, but there is no guarantee, and it can often take years to get the necessary legal and bureaucratic approvals to do so. And, of course, you don’t have a direct piece of the financial upside if the tool becomes super widely used.

The second place you can build dev tools is on an open-source project. Working in the open guarantees you will receive recognition for your work, and you also have the benefit of not having any pesky pricing considerations standing in between your users and your product. If mass adoption is your primary goal, then open source holds great appeal. Many of the most widely used developer tools—Git, Linux, Emacs, Vim, etc.—are open source projects. The downside, of course, is lack of revenue. Most open-source authors and maintainers have an alternate source of income (often working at a large tech company). Patreon and GitHub Sponsors are great, but it’s likely that only a small fraction of open-source creators will ever earn enough to make a comfortable living through sponsorship alone. The number of hours you can devote to working on open source will be constrained by where you can find sources of income.

The third place is at a developer tools company. Most such companies will be startups, because of the rapid growth in market size for dev tools over the past few years. Dev tools companies offer the benefit of aligned incentives: your users, your customers, and even your fellow engineering teammates are often the same people. If you build a great tool, then your users are happy, you get paid so you are also happy, and you and your teammates can also make use of the same tool, so that should make you doubly happy! Dev tool startups have the additional benefit of financial upside (assuming part of your compensation is an equity stake in the business). This upside could be substantial. Personally, I think we are in the early days of the developer tools market. I believe the impact of high-quality, broadly useful dev tools will someday far exceed the impact of ads-driven web search, PC operating systems, and social media. Which is to say, I think that the value of developer tool companies will someday exceed the combined value of the most valuable tech companies today.

Of course, startups also carry a downside risk. There is a high chance that the company will fail to meet its lofty goals, or may need to lay people off, or fail completely. There is no one-size-fits-all prescription for the best place to work. Personally, the principle I follow is, “Maximize expected utility subject to minimizing the risk of ruin,” where the definition of “utility” and “ruin” is up to you to define.

Regardless of whether you opt for large companies, open source, or dev tool startups, there is still the question of how to evaluate which specific opportunities and tools are worthy of your time. For that, you’ll need to rely on a combination of intuition and worldview, which we’ll discuss next.

Scratch your own itch, but understand the big picture

Jamie Zawinski once said, “The best motivator in the world is scratching your own itch.” He was talking about developer tools, and he was right. Most developer tools start with a programmer noticing they have a problem, imagining a way to fix the problem through software automation, and then writing the code that implements that automation. Building for yourself means you get to wear the hat of product manager, engineer, and customer simultaneously. This is a fantastic recipe for building something truly useful, not just for yourself, but for other people who feel the same pain. As you evaluate the landscape of enterprise developer tools, you should rely heavily on your own intuition for where pain points exist and which products offer effective solutions.

However, you’ll also want to combine your direct intuition with a broader view of how software development works—what is common across companies and sectors and what is different and specific to the segment of the market you are building for. It’s important to understand where your itch fits into the overall picture, how others experience that itch, and how their itch fits into their picture.

The way software is developed varies widely from organization to organization and even individual to individual, but there is a general “software development lifecycle” template that is fairly universal:

Plan and describe what the software should do (e.g., implement a feature or fix a bug)
Read and understand the code being modified
Write, run, and debug the new code
Test the code
Review the code
Deploy the code
Monitor the code in production and react to incidents

There are many variations on this lifecycle:

An individual programmer working on a personal project may use their editor for reading and writing code, a simple unit test framework for testing, distribute the application as a single binary, and receive feedback and bug reports through a small issue tracker.
A team of developers might use a more sophisticated issue tracker for project planning, a code search tool for understanding existing code, a variety of different editors for writing code, a CI service like Buildkite or CircleCI, Docker on top of AWS or Google Cloud for deployment, and a simple log aggregator for monitoring and error detection.
An large engineering organization may have entire teams or departments responsible for the development environment, CI/CD, provisioning compute resources, deploying to production, and monitoring and routing critical production issues to the proper first responder.

This general process and its specific instantiation by your customers is important to understand. It’s also important to understand whose lifecycle you’re accelerating—is it the individual’s, the team’s, the organization’s, or maybe some combination of the above? There’s nothing inherently wrong with selling just to individual developers, but many of the most successful developer startups sell to teams and organizations. Selling to a team means making a case to the representative of the team’s interest—perhaps someone with the title of “engineering manager”, “director”, or “head of developer productivity”. This individual may not code day-to-day.

When evaluating which dev tools and dev tool companies are worthy of your time, you should ask whether they sell to teams or individual developers, how they articulate their value proposition to different customer stakeholders, and how the tool you will help build fits into the customer’s software development lifecycle.

A brief sampling of dev tools startups

Let’s apply the software development lifecycle framework to a few dev tool startups. The following are some companies that I’ve had the good fortune of getting to know over the years and which I’ve spoken to directly on The Sourcegraph Podcast. (Incidentally, these companies are also where I’d start my job search if I were looking to join a dev tools startup—I think all of them are doing fantastic work.)

Sentry alerts developers to errors in production and helps you quickly identify the point in code where the fix should be made. It focuses on making Stage 7 of the software development lifecycle (“monitor and react”) more accessible to application developers who often spend most of their time in Stages 1-5. It also helps surface issues in staging environments, catching issues before they reach Stage 7.
Honeycomb detects production errors and anomalies and lets you drill down into an “infinitely wide data table” that provides enough context to identify the root cause of any issue. Its value prop is anchored to the concept of Observability, which encapsulates a new school of thought for how to effectively manage Stage 7, in contrast to other Stage 7 tools which use the label “monitoring” or “APM”.
Pulumi lets you describe your infrastructure as code in your favorite programming language. You define your deployment state by instantiating objects in, say, TypeScript, and the system takes care of reflecting this into production state. It makes Stage 6 more accessible to developers whose area of competence is Stages 1-5.
YourBase is a test-running service that intelligently figures out how to parallelize and optimize your builds. It inspects syscalls and performs language analysis to infer the build dependency structure so it can make choices that yield far lower build times for large codebases. It speeds the heck out of Stage 4, which can otherwise become a critical bottleneck for many teams.
Tilt is building the first-class developer environment for multi-service applications. Technologies like Kubernetes have made multi-service applications much easier to deploy, but multi-service development environments are still largely roll-your-own and janky. It resolves pain points in Stage 3 that have arisen due to recent innovation in Stage 6.
Caddy is a web server and reverse proxy that emphasizes great developer experience, extensibility, and good defaults like automatic HTTPS. It is used in Stage 6, but much more accessible to developers who spend most of their time in Stages 1-5.
Wasmer is building a WebAssembly virtual machine that runs on the server (outside the web browser). It has the potential to impact Stages 2 and 3 (Wapm raises the possibility of inter-language source code dependencies), but its most obvious value is to Stage 6 by providing a performant, easy-to-use, and secure deployment environment for a wide range of server-side applications.
Codestream is a code discussion tool that facilitates communication and information exchange around code. It aims to “shift left” a lot of the communication that takes place in code review (Stage 5) to conversations that organically happen in Stages 2 and 3.
Sourcegraph (the company I co-founded) is a code search tool that lets you find patterns, anti-patterns, symbols, references, and error messages across your codebase. It also makes it easy to dive into any piece of unfamiliar code and build a working understanding of how things work and how they relate to other parts of the code. Our core product targets Stage 2, but we have integrations with editors (Stage 3), code review tools (Stage 5), code coverage tools (Stage 4), and monitoring tools (Stage 7), because finding and reading code is something you do throughout the software development lifecycle.

A lot of buzzwords in software engineering can also be thought of in terms of what they mean for the software development lifecycle. Understanding them in this way helps me think past the hype and clarify what they actually mean:

DevOps is about 2 things: The first is making ops more accessible to developers (making Stage 6-7 accessible to people who spend most of their time in Stages 1-5). The second is automating ops with software so less manual work from sysadmins is required and the sysadmin role becomes more like the developer role (automating Stages 6-7). Infrastructure as Code can be thought of as one facet of DevOps that involves moving the definition of deployment state into a developer-friendly language, thereby facilitating automation of the deployment process.
Shift left means catching bugs and issues in earlier stages of the software lifecycle. The generally accepted rule is that bugs become 10x more expensive to fix per stage in the process. If your tool helps catch issues in Stage 4 rather than Stage 7, that means they were 100-1000x cheaper to fix in terms of time, effort, and money.
Microservices address bottlenecks in Stages 1-5 by adjusting how software is deployed in Stage 6. You have lower complexity at the source code level, but likely greater complexity in deployment (but hopefully not so much more complexity that it outweighs the simplicity gains in earlier stages). A lot of the contention between microservices and monoliths comes down to where people feel comfortable dealing with complexity. There are general statements that can be made about which is better, but a lot also depends on the domain competency of the software team members, how much of their experience is in ops (Stages 6-7) versus dev (Stages 1-5), and their familiarity with tools to manage the complexities of any given stage.

I’ll caveat all of this by saying this analysis is my own point of view. The companies discussed above might have a different articulation of their value proposition and how they impact the software development lifecycle. So might you if you do the homework of learning more about them, trying out their products, and fitting them into your own developer worldview.

And who knows? Perhaps investigating enough such companies and reflecting on personal experience will reveal to you gaps and opportunities that a new tool or company could fill. You may conclude that your best course of action is not to join any existing dev tools startup, but to create your own—but that is a subject for another post.

Parting thoughts

The past few years have witnessed an inflection point in the market for developer tools. Software development now permeates every sector of the economy and even “non-tech” companies today employ millions of programmers working on ever larger codebases that depend on an ever growing open-source universe. The opportunities awaiting builders of dev tools are immense.

So, scratch that itch. Advance the state of our craft. Become a second-order accelerator of technological progress. The cadence and drumbeat of the global economy moving forward will be “developers, developers, developers”. For makers of developer tools, that means it’s time to build.

Get in touch

If you found this post interesting or thought-provoking and would like to chat, please shoot me an email or reach out on social media. I enjoy learning from and helping others, especially those who are working on or would like to work on great dev tools.