What Held Up Devs in 2021? Long Build Times

Joseph Sibony
Joseph Sibony reading time: 4 minutes
May 16, 2022

You might be surprised to hear this, but at Incredibuild we’re all about cutting down on build times for devs and making life generally easier for large dev projects. So, we wanted to know how big of a problem long build times actually are for developers. The answer was, unfortunately, not that surprising to us.  

As part of our efforts to learn more about the issue, we conducted a survey of over 300 senior managers across the world. We asked them a variety of questions about the types of builds they run, the tools they use, and the biggest issues they face. What we found was fascinating as it was insightful. Put simply, devs waste a lot of time waiting for builds to finish, and almost all of them consider it a serious problem.  

Let’s dive into it a little bit to truly understand the issue, and what we can do about it.  

What did we find?  

First, build times are a problem, but the root cause is something largely inevitable – codebases are getting bigger. 91% of the survey respondents reported that their code bases were at least in the hundreds of thousands of lines. 76% have codebases in the millions of lines.

Codebase Size - Correct

This is also expected to expand by an average of 18.6% in 2022. The question is, how does this translate into build times, and what does it mean for devs?  

Builds already take a long time, and they’re going to get longer  

A quarter of the respondents we talked to spend more than half an hour per build. That might not seem like a lot at face value, but minutes do add up when you’re running a CI/CD pipeline or must constantly test new changes before committing them to your repo. In 2021, the average build time increased by almost 16%, and that number is set to jump in 2022 as codebases get larger and more complex.  

Long builds frustrate devs, teams, and companies – while raising costs 

Any time devs spend waiting for a build to complete is time they can’t spend completing other valuable tasks. Reading blogs and chair-jousting are great ways to spend a few hours, but they also mean your devs aren’t doing the work they need. This means less time for testing, iterating, and generally being productive.  

98% of respondents said they wasted time waiting for builds to finish, and 91% consider this a problem. Moreover, slow build times came in third among the top frustrations devs face in their day to day work. For devs working on the cloud (and nearly half of our respondents do) and looking for cloud optimization strategies, slow build times mean more compute resources used, more instances spun up, and more costs.  

Wasting time

The tools that make code better are also making builds longer  

It’s not all about writing more code – it also needs to be good quality. Unfortunately, the tools devs are using (such as static code analysis, which 76% of respondents used) result in slower builds. This means that as codebases get larger, these methods and tools will continue to eat up more time and become bottlenecks to faster development cycles.  

The solutions we’re using are a band-aid, not a fix  

The problem isn’t going away any time soon, so our solutions can’t be short-term ones. Even so, we continue to look for fast fixes to a permanent issue, and this could backfire. Many organizations looking to cut down build times looked into getting more and better hardware and reducing the size of their codebases (whether by slashing code or refining it).  

These are great short-term fixes, but there’s only so much hardware you can buy and upgrade, and code can only get so perfect before you start to see diminishing returns from “fixing” it. These solutions tend to become less effective and more expensive as time goes on, so a better solution is needed.  

Having the right tools isn’t a silver bullet, but it is a game changer 

There’s not a single solution to the issue of slow build times but having the right tools in place can help drastically reduce them. Our survey found that having the right tools in place resulted in over an hour being saved in productivity every day. Spread out over a year of work, that’s 36 days. If we really wanted to get specific (and we do) that’s about $20,000 in savings per year based on the average developer’s salary. These productivity savings are massive and could result in much better products, more space to hire needed developers, and more time to test, debug, iterate, and release better products.  

Survey Time Saved

Getting faster in 2022 

Acceleration isn’t just a buzzword for the future – it’s a necessity in a world where our apps are getting bigger and our users’ attention spans are getting shorter. To remain competitive and put out better products, dev teams need to be fast and have good quality, and as we’ve seen, that’s not always easy.  

Want to learn more about dev build times and how organizations are cutting down on time wasted?  

Read the full report now!

Joseph Sibony
Joseph Sibony reading time: 4 minutes minutes May 16, 2022
May 16, 2022

Table of Contents

Related Posts

4 minutes How Caching Makes for Faster Builds on The Cloud

Read More  

4 minutes Build Cache Today and Tomorrow

Read More  

4 minutes The Future of C++ – Part 2

Read More