In this document, I want to provide a model on how to calculate the costs of your builds and the return you get on improving it.
Developers and build engineers are under constant pressure to ship faster and more frequently. This requires fast feedback cycles and thus fast builds. At the same time, cloud, microservices, and mobile have made our software stacks more complex. Together with growing code bases, and without taking any actions, this will slow you down as your builds become slower and build failures are harder to debug.
Improving this is a huge organizational challenge for build engineers and development teams. To trigger organizational change it is important to have quantitative arguments. Inefficient builds do not just affect your ability to ship fast they also waste a lot of your R&D bandwidth.
Some of our customers have more than 100,000 Gradle build executions a day. Most medium to large engineering teams will have at least thousands of builds a day. For many organizations, this is a multi-million dollar developer productivity problem that is right under your nose. And every effort to improve it should start with assessing its impact.
Meet our example team
Our example team consists of 200 engineers with the following parameters:
|CM||$1||Cost per minute of engineering time|
|DE||230 days||Working days of an engineer per year|
|CE = DE * CM * 8 * 60||$110,400||Cost per engineering year|
|BL||2000||Local builds per day|
|BCI||2000||CI builds per day|
|DW||250 days||Number of days the office is open|
|BYL = BL * DW||2000||Local builds per year|
|BYCI = BCI * DW||2000||CI builds per year|
The example numbers above and later in the article reflect what we see typically in the wild. But the numbers out there also vary a lot. For some, we have better averages than for others. The example numbers are helpful to get a feeling for the potential magnitude of the hidden costs that come with builds. Your numbers might be similar or very different. You need your own data to get a good understanding what your situation is and what your priorities should be. The purpose of this document is to provide a model with which you can quantify costs based on your own numbers.