Software Will Supercharge Developer Productivity: Why We’re Excited About DX
Software developers spend their days chasing the elusive “flow state:” headphones on, Slack notifications paused, dev environment humming along, context switching to a minimum, and delivering a significant amount of valuable code and/or solving a hard problem. The unfortunate reality is developer flow is constantly interrupted by what Jyoti Bansal, founder of Menlo portfolio company Harness, calls toil (graphic below): faulty environments, flaky tests, slow builds, cross-team dependencies, and the like, grind productivity to a halt. At Menlo, we see a huge opportunity in the modern developer experience stack that minimizes blockers, enhances collaboration and gets high-quality functionality to market faster.
The market for dev tools (and the underlying theme of developer experience) is massive—every modern company is a software company in some capacity, and engineering productivity is a force multiplier in their innovation. Product velocity makes for happier developers and is a catalyst for recruiting and retaining top tech talent. Toil leads to frustration and curtails innovation.
This is why we see so many companies investing in tooling and the “developer experience” role has been a critical function for leading edge companies. At Menlo, we are excited to partner with the next generation of companies helping engineers minimize this toil and get back to innovating.
To validate our hypothesis around this pain and need, we conducted over 30 interviews with thought leaders in the space. This helped us hone our thesis around priority areas: what solutions were most in need and had the potential to have the biggest impact. Below are 8 priority areas, the obligatory market map, and some specific ideas within each area. And we start with the rise of the DX function…
Why now? The rise of DX investment
We certainly validated the rise of the developer productivity professional within leading engineering orgs (sometimes called developer experience or DX). Their mandate is to ensure their organizations are equipped with next-gen tooling that helps developers spend more time writing code, getting functionality into production, and spending less time on toil. Better dev productivity metrics correlate to business metrics: time to market, quality, cost. Big tech companies (including Google, Uber, and Twitter) were the first to hire developer productivity teams in the mid-2010s. Developer productivity gained even more recognition in 2018 when Google’s DevOps Research and Assessment (DORA) published a study naming four key productivity metrics to track (deployment frequency, mean lead time for changes, mean time to recover, and change failure rate). Since then, DX hiring has increased 10x, leading to a huge spike in investment in tooling for developer productivity.
It became apparent to us that this increased focus on DX would make measuring developer productivity a top priority. This key insight prompted us to invest in Sleuth, a solution that helps teams at companies such as Atlassian and LaunchDarkly track DORA metrics.
Emerging priorities in developer productivity
Measurement is important, but only the tip of the iceberg. We strongly believe there are many areas of investment in DX tooling that will help improve developer productivity, enhance job satisfaction, and accelerate product velocity. From conversations with dozens of developer productivity professionals from leading engineering organizations, we learned the pace of innovation and DX investment is accelerating across these focus areas:
- Cloud-based collaborative codespaces
- Next-gen environments
- API tooling
- Test automation
- Next-gen issue tracking
- Software supply chain security
- Synthetic data
- Service catalogs
1. Cloud-based collaborative codespaces
Airbyte’s head of DX recently published his prediction about the End of Localhost. We tend to agree with him. We see two drivers behind the shift to cloud-based collaborative dev environments:
- Increased complexity: As repositories increase in complexity, it’s more and more untenable to run all the necessary services and dependencies on a local machine. Installing all the dependencies is an error-prone process that slows down ramp time, and even then it’s impossible to get the local environment to mirror the production one. Code that works on a developer’s local machine is likely to run into issues when it gets deployed to a more complex environment.
- Increased collaboration: Writing code is one of the only remaining business workflows that happens in a single-player local machine environment. Given the increased need for collaboration throughout the SDLC (among developers and across other stakeholders in Engineering and Design), we think it’s likely that a more collaborative software writing experience will emerge – just as Google Docs / Notion replaced Word for nontechnical workflows.
Key emerging players like Gitpod, Chromatic, and Replit envision a future where standing up a developer environment, writing and testing features, and receiving quick feedback from other stakeholders is a seamless process.
“Remote development – not using a laptop for main development—is a growing thing. We don’t want to break our developers out of their flow. They shouldn’t have to go to multiple tools for debugging and authoring code.”
—Scott Holmes, Director of Software Engineering and Developer Productivity at Coinbase
2. Next-gen environments
The problem: With the shift to microservices architecture, standing up production- and pre-production environments is more complex and expensive than ever. The old approach no longer works: the canonical pattern of a few testing environments, one staging environment, and one production environment creates significant bottlenecks. Without sufficient investment in test environments, developers must wait for a test environment to become available, and faulty pre-production code can take the test environment down for the entire organization. Even with the best agile practices in place, environment bottlenecks anchor software teams to waterfall-level productivity.
The solution: On-demand test environments help parallelize the software testing process and reduce environment drift, helping software teams ship higher quality code faster. Ephemeral, up-to-date, production-like environments help engineers isolate their changes and diagnose issues quickly before they show up in production. These next-gen environments providers also have the opportunity to automate production deployments, diminishing toil for DevOps engineers as well.
We are excited by the work new players like Release and Okteto are doing to streamline the development process.
“Environment availability for testing is one of our biggest pain points. Newly released code often breaks other new code coming out, creating operational overhead. To get a working environment it can take 2-3 days, which is a big problem. If you have a startup that solves this, you are sitting on gold.”
—Platform Engineering Director at a public fintech company
3. API tooling
Around 2010 SaaS took off and APIs were offered as products for the first time. Vendors such as Mulesoft emerged to help business users connect SaaS APIs, while Postman helped API developers build and test their APIs. In addition, API gateway products such as Apigee (later acquired by Google) and Kong emerged to help API businesses manage external traffic and bill for their APIs.
API-first development is now standard practice across the tech industry. The new API-first world requires updated tooling. API architecture is the new UX design: it’s crucial for organizations to ship a consistent developer experience with clean, easy-to-use APIs. Propelling this: The popularity of new API protocols such as gRPC and GraphQL, which necessitate an updated design approach beyond what incumbents provide.
New API design interfaces such as Speakeasy and Stoplight help teams collaboratively design APIs with clear, auto-updated documentation, a consistent architecture, and usage observability to help detect problems.
“The idea of an API-driven organization is pretty strong – the benefits are strong, especially in giant corporations. As we move away from our monolith, how do we create the right boundaries for API first development? We want to help our teams create APIs with the right authentication, rate limiting, and security features, automatically bridging gaps between teams.”
—Chris Cholette, VP Productivity and Site Reliability Engineering at Tripactions
4. Test automation
Shift-left software testing is in full swing, with developers writing their own test cases for the code they ship. While this cultural shift is increasing the quality of the tests, writing and maintaining test automation suites is a slog for developers. Points include:
- Frequent updates needed: Test suites tend to be brittle and inflexible, necessitating tedious rewrites from release to release.
- Flaky tests: Tests that fail intermittently for no apparent reason are a time suck. They decrease developers’ trust in test suites, since devs aren’t sure if failures are due to true defects or issues with the test itself.
- Root cause analysis: Especially in complex, highly dependent repositories, developers might spend hours or even days combating test failures without a clear understanding of the underlying issue.
These testing pain points are perennial. No clear leader has emerged in the crowded commercial tooling landscape, creating an opportuntiy for the right company. We’re on the lookout for new solutions that clear these blockers and help teams test software quickly and comprehensively. So far, we’ve been impressed with the productivity gains that QA Wolf, Functionize, and Mabl provide.
“Large organizations are probably not doing every test on every commit. You could with the cloud, but it would cost a fortune, so you pick limited smoke test suites to run. When test failures happen, it’s hard to diagnose them. Out of 390 commits in the last week, which one was it that caused the problem? I’ve had this problem at four companies!”
—Tara Hernandez, VP Developer Productivity at MongoDB
5. Next-gen issue tracking/roadmap
Prioritizing the right ideas, tracking roadmaps and maintaining product quality can mean the difference between the success and death of a company. The leading solution for this use case, Jira, is a 20-year-old tool that suffers from poor usability and an inflexible data model. These issues can cause inconsistent Jira adoption, making the tool less trustworthy as a source of truth for product requirements. Ultimately, this creates additional toil for developers who must hunt down requirements in documents and on Slack.
We are energized by new tools that combine the power of Jira with a more intuitive and modernized interface. New tooling can also connect to the GTM stack, assigning dollar and customer value to issues and features. Tools like Height, Cycle, and Linear offer a snappy user experience that transform previously bureaucratic overhead into a true hub for alignment and collaboration.
“We’re a big Jira shop, but we don’t have a great solution around roadmapping or dependency management. We have severe dependencies across organizations, and we need a product management tool to manage dependencies, capacity plan, and visualize data.”
—VP Developer Productivity at a public payments company
6. Software supply chain security
Security is shifting left as well, putting increased responsibility on developers to ensure that their code is secure by the time it’s merged. One way developers can drive cybersecurity is by securing the software supply chain—reducing the attack surface of vulnerable third-party dependencies. This is critical: Sonatype’s 2021 State of The Software Supply Chain reported a 650% YoY increase in associated attacks, including painful examples such as Travis CI secrets, OMIGOD agent, and Log4Shell.
Traditionally, software supply chain security companies focused on the code level, with code scanning and application security testing solutions that were noisy, slow and ineffective. We’re excited about new players that allow developers to build “secure by default,” remediating actual threats without being inundated by hundreds of alerts. A next-gen solution should also provide comprehensive visibility and remediation capabilities across all third-party threats at the code, pipeline, and build levels.
(You can read more about how Menlo approaches software supply chain security in this deep dive.)
“Our top priority in security is our ability to build our security policy into the software writing and CI/CD process. We want to shift left and have a simple, reliable way to enforce policy changes at runtime.”
—SVP of Technology Partnerships at a major bank
7. Synthetic data
In the testing process, developers need large datasets that mirror the real world in order to verify that their code performs at scale. Using production data, however, introduces privacy breaches, especially when the company’s data deals with PII (e.g., healthcare data, financial data). It’s a difficult technical problem to create anonymized datasets that capture the subtle, intricate relationships present in real user data.
Quality data synthesis companies connect to the production data systems that companies use to generate safe, realistic, and de-identified data for QA, testing, and analysis. These datasets provide all the benefits of testing with production data, without any of the privacy risks of using the real thing. Tools like Tonic and Gretel have been effective in providing commercial solutions to this pain point.
“Test data generation and management is difficult especially for a company with huge monolithic Oracle databases. There’s no good way for us to put that in a QA environment in Google Cloud. Tools that can synthesize and anonymize data in a realistic way are important for us.”
—VP Developer Productivity at a public payments company
8. Service catalogs/IDPs
Coding in a microservices environment can get complicated quickly, especially for new team members. Service catalogs and internal developer portals (IDPs) are increasingly necessary to help devs discover and understand all the company’s software, services, docs, APIs, and tools. They provide a UX layer to quickly answer questions about software ownership, deployment, and dependencies, as well as templates and patterns to stand up new services. Service catalogs not only help developers get started on new projects, but they also ensure a consistent software design pattern across a large engineering organization.
Backstage is a popular developer portal that was open sourced from the team at Spotify. Now, commercial tools like Cortex and Roadie have emerged that provide a premium Backstage experience for enterprises. Popular SRE tooling FireHydrant also released a service catalog. These solutions will be hugely beneficial as engineering organizations grow and codebases become more complex.
“We think it’s important to give developers a place to start—an entry point. Open source technology coming from Spotify, Backstage, provides templates, tooling, and scaffolding. If teams want to introduce new microservices in a different framework, we can help them make their service performant and high quality.”
—Mike O’Brien, Sr. Director of Product Infrastructure at Flexport
These areas of focus are just the beginning—the team at Menlo is actively investing in the developer experience and will continue to seek out software that decreases developer toil and unlocks productivity. If your company is helping developers get back to doing what they do best (aka innovating), we would love to hear from you!
Special thanks to all who participated in our research panel for sharing your insights and expertise.
