Instead of focusing on output, think about increasing testing and research and being willing to scrap projects that don't seem likely to succeed.
Developers are the new kingmakers, the saying goes, and so companies spend a great deal of time trying to enable developers to move faster. And faster. And faster. The problem with this focus on speed is that “development velocity … and launch throughput are entirely the wrong optimization,” argues product management guru Itamar Gilad. It’s not that developer productivity is bad. Far from it. It’s just that obsessing over development speed has blinded us to the greater importance of delivering fewer but higher-impact projects.
In other words, less really can (and should be) more when it comes to software development.
Less is more
It’s a bit like the Cheshire Cat’s response to Alice when she asks him which way to go in Wonderland:
Alice: “Would you tell me, please, which way I ought to go from here?”
The Cheshire Cat: “That depends a good deal on where you want to get to.”
Alice: “I don’t much care where.”
The Cheshire Cat: “Then it doesn’t much matter which way you go.”
In the case of software developers, they likely know where they’re trying to go (building a particular application, etc.), but they often haven’t really thought about which projects they could and should scrap to get to the happy place faster. Jeff Patton, founder and principal of Jeff Patton & Associates, and author of the bestselling O’Reilly book User Story Mapping, puts it this way: “One of the common misconceptions in software development is that we’re trying to get more output faster. Because it would make sense that if there was too much to do, doing it faster would help, right?”
Like Alice, we’re hurrying to get somewhere, but Patton’s point is that we need to be much more deliberate about where we hope to go, and much more thoughtful about how we will arrive. He continues, “If you get the game right, you will realize that your job is not to build more—it’s to build less.” How’s that? For software developers, “your job is to minimize output, and maximize outcome and impact.”
Less code, but more impact. That’s the formula for success. But it’s not what many development teams do. For too many, as Gilad details, “a product group that has two-thirds of the output really [can] create four times the impact.” The key, he stresses, is that “most of what we create is a waste, [so] chasing output is actually creating more waste, faster.”
All of which sounds great, but telling developers to “do more good things and fewer bad things,” is hardly actionable. The trick, Gilad outlines, is to introduce more research and testing earlier in the development process, coupled with a willingness to scrap incomplete projects that aren’t on track for success. It’s not that developers will sit around thinking about success but not shipping. Rather, “you should increase throughput, but not of launches.” Instead, focus on running more “tests and experiments.” By doing so, you’ll end up with fewer projects but ones with a higher impact. This willingness to shed bad code early can make a huge difference.
More and faster
All this is not to say speed is bad. In June 2022, developers turned to GitHub Copilot to generate 27% of their code. Just a few months later, in February 2023, that percentage jumped to 46%, according to GitHub. What’s behind this shift? Among other reasons, developers want to deliver more code faster, and letting AI handle the more tedious aspects of coding can help. This is also why open source remains such a critical component of software development. As Professor Henry Chesbrough recently explained, even companies that worry about security or other perceived problems in open source keep using it because it improves development speed: “If we were to construct the code ourselves, that would take some amount of time. It might be cheaper for us to do that, but our developers aren’t just sitting around with nothing to do, and this code is available now.”
It’s this same need for speed that has enterprises turning to platform engineering teams to construct guardrails for their developers. By offering developers a preapproved environment with which to build, Weaveworks CEO Alexis Richardson says enterprises can enable their developers to “focus on innovation, not plumbing.”
Citing data pulled from how developers use the O’Reilly learning platform, Mike Loukides notes, “Software developers are highly motivated to improve their practice of programming.” Figuring out how to improve coding practices was the top result across O’Reilly’s platform, well above security, data science, mobile, etc. Developers and development teams keep trying to go faster, which is good.
Part of that focus on speed should also be speed in dumping bad code or ill-conceived projects, which becomes easier if we push for more research and testing up front. Returning to Gilad, our focus should be on doing less in order to deliver more. Testing is the key to getting there.
