This is the second post where I cover one of the 13 categories of technical debt identified by Alves et al. This post will cover Build Debt. Let’s take a look.
What Is Build Debt?
The authors of the paper, titled Towards an Ontology of Terms on Technical Debt, define Build Debt as “build related issues that make this task harder, and more time/processing consuming unnecessarily.” Furthermore, the “build process of a project can contain very unnecessary code to the customer. Moreover, if the build process needs to run ill-defined dependencies, the process becomes unnecessarily slow.”
Let’s break that down a bit. First, “the build” is the process of transforming source code into executable software. This is often more than compiling the code. Tasks like running tests, preparing database changes, and static code analysis are just a few examples of what the build process might contain.
Build debt is any set of issues that make this process more difficult and/or more time-consuming. Examples include:
- lack of automation: if parts of the process are to be done manually, this is time-consuming and error-prone
- unnecessary targets: builds that compile, test or perform other actions that are irrelevant to the final output of the build, unnecessarily slow down the process
- dead flags: builds that accept parameters to modify their behavior sometimes contain such parameters (or flags) that are no longer necessary, because the same value is always passed
- complex builds: whether done manually or automated, complexity in the build process discourages engineers to modify and improve the build process
- flaky builds: if builds are unreliable, the teams lose time re-executing the process
- slow builds: slow builds delay the feedback developers need to know if their code changes didn’t break anything
The build process is an important step in the software development lifecycle. Build debt identifies problematic issues in this process and can significantly reduce the quality and velocity of a team.
Causes Of Build Debt
In my experience, build processes usually start out simple enough. But as systems grow, build processes often get out of hand. This even happens to senior engineers. Especially when they are smart enough to set up complicated processes, but lack the professionalism to take a step back and think if such complexity is a good idea.
Not adhering to industry standards and best practices is often the cause of complicated builds. Also, not taking time to maintain and clean up the build process.
Solving Build Debt
Instead of “rolling your own” build process, teams should automate with existing tools and split up in smaller, separate builds if things get out of hand.
The build process should be maintained just like the source code of the application is. Teams should take time to remove unnecessary steps in the process and automate as much as possible.
If there is already a large amount of build debt, a series of steps may be necessary to get the build in a healthy state. It’s possible that this effort may take some time.
The Business Case For Reducing Build Debt
If the build process is still manual, there is a lot to be gained from automating it. An automated process will very unlikely produce errors and will often run faster. An automated process can also serve as an “impartial referee” to the team on code changes (avoiding the “it works on my machine” statement).
Automated builds that take a long time to run or are unreliable, mean the developers have to wait longer to get feedback from this “impartial referee.” Either they will waste time doing nothing productive, or they will start some new work. If the build fails, meaning their code wasn’t valid or up to standards, they need to switch contexts back to their first task to investigate. This is highly inefficient for knowledge workers, because it means recreating the mental model of the first task.
Ideally, a build process provides a developer with fast feedback of whether or not they can continue with the code they just wrote. In some very extreme cases I’ve seen, a long build meant developers could only finish a maximum of one item of work per day.
This shows it pays off to invest some time into reducing your build debt and setting up a fast, maintainable and automated build process.