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.
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.
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.
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?
