Measuring the Value of Development Acceleration

Return on investment (ROI) has become a key measure when considering whether a tool, methodology, or strategy is worth implementing and maintaining in an organization. Even so, ROI is easier to measure in some cases than others and often measures only the result – money. This view is valid and necessary, but it often excludes critical components of the total value picture.  

What about a platform like Incredibuild, which provides development acceleration – a benefit that has significant intangible benefits and value to go along with the tangibles? It might seem too abstract to define, but it’s possible – and deceptively simple – to understand the value these platforms provide. 

Let’s explore the value of acceleration across two key values – development time and iteration frequency.   

Quantifiable value

Let’s start with a basic premise:  

Time = Money  

This is nothing new, but let’s add a new layer: 

Time = Speed + Quality 

Before we dive too far into the well of aphorisms, let’s break this down. We’re simply stating that if time is value, which is a combination speed and quality of work, then value comes from saving considerable time on your development.  

With a foundation laid, let’s establish some key concepts we’ll be using from here on out:  

• Local and centralized builds – Builds are required to run tests and understand how code works during development. They can happen locally on developers’ devices allowing for immediate changes, or centrally (CI), incorporating changes and updates from multiple devs and teams.  
• Build wait times – Simply put, this is how long builds take to complete. A build means you can’t work on the code while you wait for it to compile and incorporate new changes, and longer builds lead to context switching and time wasted.  
• Incremental and full builds – Incremental builds are usually run locally and take less than a full build. However, events such as new branches trigger a full build of the codebase. Similarly, large teams might have members do a daily “get latest”, which can trigger incremental builds that might take as long as full builds.  

Build speed impact on frequency  

Build times – and by extension, build frequency – are one of the largest factors impacting time to market. Good software is built on iterations, and slower cycles mean less can get done, fixes take longer to fix, and release windows become much tighter.  

Most organizations prefer to achieve full “build-per-commit” – the ability to trigger a new build whenever there is a new commit to a branch – but low build frequency makes this more of a pipe dream. While there are myriad reasons to strive for higher build frequency, two stand out: 

• Providing feedback to developers much earlier in the process 

• Enabling much faster “who broke the build” resolution. 

Lower build frequency also comes with much greater risks to code quality. Fewer builds per project means that more code additions are included in every build. It also means that more potential errors and a harder time sifting through dozens of code additions to determine where the fault lies. Build-per-commit means only a single code change is examined. Thus, faster builds and higher build frequency reduce time spent searching for errors and fixing code and lead to better software.  

Quantifying the value of build time reduction 

To illustrate, let’s break down an example of Incredibuild’s acceleration. In this case, we can measure the difference in both incremental and full builds when using Incrediubuild:  

This is a broad overview, so let’s add some more layers to our example. Imagine you have the following: 

• 30 developers on your team  
• 22 workdays per month (average) 
• $0.75 dev cost per minute (Computed based on $100K annual developer cost divided by months, 22 hours a month, 8.5 hours a day and 60 min an hour) 

And now, we can start calculating the dollar figures of our savings.  

First, time saved per developer, per day is calculated as follows: 

(Time saved per incremental build x iterations) + (time saved on full build x iterations) = total time saved
(3 min x 4) + (30 min x 1) = 42 minutes saved 

Next, we can find the total time saved per day by multiplying the above result by the total number of devs: 

42 minutes x 30 developers = 1,260 minutes (approximately 21 hours) 

And extrapolate it to a full month 

1,260 minutes x 22 days = 27,720 minutes (about 3 weeks) 

Now we can understand the dollar value in savings:  

27,720 minutes x $0.75 = $20,790 direct dev productivity savings per month 

And spread out across a full year:  

$20,790 x 12 = $249,480 direct dev productivity savings per year 

The estimates above assume build frequency is the same as before using Incredibuild. If we were to factor in the boost to iteration frequency (from four to eight iterations for incremental, and one to two iterations for full builds), we can assume the savings we demonstrate above could easily double to almost $500,000 per year!  

Factoring in CI/CD builds 

Our calculations so far have focused on individual devs running builds locally. However, development today does not happen in isolation. Build farms, for instance, complete builds much more frequently and throughout entire months as organizations seek out continuous builds. When we factor in the impact of Incredibuild on CI/CD pipelines and builds, we can see an even bigger boost.  

For this example, we assume that approximately 33% of builds impact developer productivity, as they occur during work hours and prevent devs from continuing work until builds complete. Let’s use the same formulae we use above, but add the centralized impact. First, let’s calculate savings per dev per day:  

Time saved on centralized builds x iterations x percentage of builds that impact dev productivity = total time saved per dev per day  

80 minutes x 3 iterations x 33% = 80 minutes saved 

And let’s extrapolate that to total savings per day: 

80 minutes x 30 devs = 2,400 minutes saved  

And then per month:  

2,400 minutes x 22 days = 52,800 minutes saved (about 1 month 6 days) 

Now let’s explore the financial side:  

52,800 minutes x $0.75 = $39,600 direct developer productivity savings per month 

And finally, let’s extrapolate to yearly savings:  

$39,600 x 12 = $475,200 = direct dev productivity savings per year 

As with our first example, we’re not accounting for the increase in build frequency in our calculations. This means that in real terms, comparative savings could reach nearly $1 million per year.  

The true impact of developer acceleration  

In both cases, savings before build frequency increases are already significant. By aiming directly at improving frequency by reducing build times, teams of this size can achieve annual savings of between $750,000 and $1.5 million! It’s also worth noting that these numbers will increase as code base size and project complexity increase over time.  

We’ve focused extensively on the tangible benefits of build acceleration, but it’s also worth noting that these direct impacts also create significant intangibles, including: 

• Increased frequency due to faster builds  
• Faster time to market and an increase in the number of yearly releases  
• Focused, happier developers  
• More time for creativity and improved code quality.  

Value doesn’t need to be some abstract concept we tout when finding solutions. Acceleration is more than just going faster; it’s providing better quality and reduced time to market.  

See how Incredibuild can boost your ROI  now with our online ROI calculator!