#008 Orlando thinks: Build time is life time
Hello everyone, it’s me, Orlando. I’m an Apple fanboy and software engineer at arconsis. From time to time, I publish an article from the series “Orlando thinks” in which I highlight a specific topic that I see as important or exciting. Sometimes it might be just certain aspects of everyday life, but sometimes it might be tips, hints, thoughts, or appeals — but non-sense is not excluded either.
I want to write about build times. About long build times. And about the frustration that can arise here. But first, I want to thank Mike Hay, whose tweet inspired me to write this blog article.
Link to Twitter (Hint: It’s a thread)
Mike Hay brings up 5 points on “Why do developers complain about long build times?”.
- Automated testing systems need full builds to run tests
- Slow builds kill momentum.
- When the tools are so slow that it feels like they are not working, they become a new problem to solve
- The tools sometimes force a full build — it is unavoidable
- Developers have to build dozens of times per day
Especially point 3 appealed to me a lot, and I would like to look at it in detail.
But — before we continue — why don’t we take care of this earlier to keep the build time bearable?
“Forgotten” technical debt
Should you avoid changes that lead to increased build times in the first place? Yes, of course, that is desirable. Always pay off any technical debt at regular intervals. It’s like tidying up and cleaning your apartment — better to do a little every week instead of eventually sinking into chaos.
The bad thing is that build time is often considered late. No matter how modular and architecturally sound a project is, build time can still suffer. For example, necessary frameworks have a detrimental effect here. (Many of you might know this: You have to include Framework X for marketing reasons. *sigh*). In addition, a project grows organically with its features, which will always increase the build time. It is less noticeable if this has increased too much at many different points. If we then realize that it simply doesn’t work anymore — we have long since missed the point for timely countermeasures.
Admittedly, this also applies to the technical debt you naturally build up in your software architecture — only we now have a better view of it.
So — Assuming our build time is too high. Why is that a problem?
Functionally broken
The issue is that something that is just very slow feels broken.
We all know this effect when we try to load a website with a slow internet connection. When I see a loading indicator for a long time, I notice the reflex to want to reload directly — it expresses “takes too long, seems broken, try again”. Nowadays, this is also my problem with internet providers in Germany throttling my speed to the “Edge age” after my data volume ends. Yes, in fact, I still have a connection. But actually, it’s functionally broken. That’s precisely the effect you experience as a developer with long build times.
And something that you think is broken, you want to fix.
You try to solve the problem
Things start to happen, and the focus within the team shifts. So you start spending a lot of time on maintenance. For achieving quick success, it is best to proceed iteratively. As I mentioned above — a little bit at a time, rather than all at once. Basically, that is correct. But I think this iterative approach works out easier for, e.g., performance problems at runtime. So you can introduce a new thread in one place and make algorithm X a bit more efficient. Or with monolithic code, where you can also try to make at least a small part more readable and modular.
On the other hand, often, only radical and more significant changes have a noticeable impact on build time. This is especially true when smaller performance tunings that boost some seconds have already been achieved as a “quick-win”.
But if developers are aware that they can’t just work on the project setup and tooling for two months now, they try to pour the giant mountain of work into a “technical roadmap”. This is where the “technical roadmap” starts to compete with the actual product roadmap.
Focus gets lost
Here we go, you start planning “technical stories” and trying to justify them to product owners. As a developer, the struggle begins to alleviate the daily pain that non-developers may not be able to comprehend fully. In parallel, you ignore the actual useful features that your users are waiting for.
Admittedly, these moments can happen with any technical debt. Therefore, we should always be clear: The moment when technical debt hampers your project is not when you suddenly realize that your product is hardly releasable. Instead, it starts much earlier — when more time is invested in meetings, infrastructure issues, and project setups.
Watch out for these symptoms early on — they are an alarm signal!
Deal with it?
The setup itself is okay-ish; you understand the code, you think the codebase is modular enough, and so far, there is no real reason to worry? Then why don’t we just live with the fact that a build sometimes takes 30–40min?
As mentioned above, if something feels broken, it’s hard to live with it. But there are more dangerous things than losing focus on the real roadmap. Apart from the fact that you might get to the point where releases get hard, the psychological component is often completely forgotten.
Developers who only stare at loading indicators and constantly wait for their code to be built become dissatisfied. You never get into the state of a natural “flow”. Even the most minor changes, like hiding a label in the UI, adjusting the corresponding unit test, pushing, and then waiting on the CI until the build is green becomes a matter of 1–2h. This is not what developers envision from efficient work.
It gets even worse when resignation sets in within the team: “It’s always been like this — there’s not much we can do about it anyway”. That’s the point where trenches open up, and you have to be careful as an employer that developers don’t run away in droves.
The solution?
Unfortunately, if you expect “the solution” from me now, you will be disappointed. Team constellations are always a complex structure. Every situation and every setup is very individual. And long build times are not long build times everywhere.
It’s just important to understand: With build time, it behaves like with any other technical debt — postponing problems never makes it better.
Address issues regularly and as early as possible!
And if problems keep recurring over a long time and you notice that the maintenance effort is not decreasing even after trying to work on the issues, again and again, you might want to think about the fundamental problems.
Especially in larger companies, it is often not appreciated to entirely question solutions that were seen as innovative 4–5 years ago and to throw them away if necessary.
But we have to accept this short-livedness in today’s complex technical world. There is no such thing as future-proofing. We can only ensure that we remain responsive at all times.
However, long build times, unfortunately, do not help here 😊
Make sure your product owners/managers/whatever are aware of that! Build time is working time. And working time is life time. And we don’t like to waste life time with senseless waiting.
Cheers 🍻
Orlando
