Why we should care about local build times

What is the main activity of developers? Waiting. What sounds like a bad joke is unfortunately not one. The reality is that developers always have to wait for things – e.g. for the local build.

The problem

Software is becoming more complex, the code base larger – builds take longer. At the same time, the pressure to release faster is increasing. The bottleneck “build times” is therefore becoming more and more relevant.

Briefly touched on above, here is a summary of the reasons why long build times occur:

Computing power of the computer: Computers with outdated or poor hardware can slow down the build time.
Size of the project: Larger software projects with many files and components usually take more time to compile.
Dependencies: If the software depends on other libraries or components, these must also be integrated.
Scope of change: If there are many code changes, this can take more time.
Errors and problems: If errors occur during the build process, they need to be fixed before the local build can be successfully created. The time taken to find and fix bugs can vary.

But what are the effects of a long build time?

Steven Lemons describes the problem in a particularly tangible way in his post on Medium. The waiting time for builds can be divided into three categories.

Category	Description
Short waiting time	Unobtrusive; work can continue immediately without interruption.
Medium waiting time	Perceptible; The current train of thought is interrupted.
Long waiting time	Frustrating; You do other tasks/browse etc.

So the longer the wait, the more likely that something else will be done. This is a completely normal process that is comprehensible. Anyone can easily observe this when visiting a website. If a page takes too long to load, the tab is closed and an alternative is tried.

With a website call, however, there is a difference: we can immediately call up a page that is equally relevant and leads us to our goal. The task we are working on remains the same.

However, developers are forced to either do something else (change task) or to bridge the waiting time in another way (memes pages are also very popular here ;)).

This leads to several problems:

In business terms, productivity is reduced. Resources are used inefficiently. We have broken down exactly how much slow builds actually cost (hint: a lot!) in the article “The cost of long build times“. On an individual level, a long build time leads to frustration.

By constantly waiting, developers concentrate on several tasks, have to constantly familiarise themselves with new tasks and make more mistakes. If the waiting time is used to do other things, they may even overlook the fact that the other task actually still needs to be worked on. At the end of the day, all this costs energy.

In this context, Brett Schuchert talks about other hidden costs, which are rarely measured and become apparent in the form of longer processing times for tasks, working hours and higher fluctuation. All these factors are backed up by a stackoverflow study: “Being productive” is named as one of the most important influences that make developers happy at work.

Far too often, this problem is also simply accepted and put up with. This should not be the case.

The solution

LinkedIn, for example, took this problem very seriously and already worked on the build time problem in 2018, reducing it from 60 minutes to 15 minutes. Original quote: “Build times improved by a factor of 150% to 400%, depending on the size of the application code. We’ve seen over 1,000 hours of productivity gains across various stages of the build lifecycle per quarter.“

So the solution is to continuously optimise and experiment. Sometimes, however, short-term quick fixes are made by simply buying more and more powerful hardware. Here, however, only productivity is taken into account.

In the long run, this is not very sustainable. This only addresses the technical problem and perhaps increases productivity for a short time, but only changes the frustration level of the developers in the short term.

The new hardware quickly delivers nice results at the beginning, but the performance deteriorates again. What’s more, the development environment has to be set up again and again, which eats up time every time for large and complex projects – even if this changes to a certain extent with experience.

With the right tools, however, some ground can be made up – and sustainably. At incredibuild, they found that using the right tools resulted in an hour of productivity gain. That’s 36 days a year.*

A very recent example: At Uber, the problem has been solved with the use of Remote Development Environments. We have summarised the result in the article “5 companies that already use RDEs”. Slack also uses Cloud Development Environments and has been able to reduce the build time and thus ensures higher developer satisfaction. Original sound: “I’m a huge fan – this work has greatly improved my productivity and my quiet laptop fans really thank you.“

Speed is a factor in surviving in the marketplace. Slow build times are a blocker that prevents this. Looking at the two levels: Productivity and Developer Satisfaction, decision-makers can make a significant contribution to managing the company comprehensively and sustainably.

Conclusion

Developers spend a lot of time waiting for things, such as the local build.
There are several reasons for this: Computing power, dependencies, scope of change, etc.
The result: reduced productivity, frustration for developers.
The solution is to work continuously on optimisation and to use the right tools. Two factors should be considered: 1. does the solution have a sustainable and positive effect on productivity? 2. does the solution have a sustainable and positive effect on developer satisfaction?
Remote Development Environments fulfil these two caspects. Take a look at it.

* https://www.incredibuild.com/blog/what-held-up-devs-in-2021-long-build-times