Slow builds and fast deploys

What would you think if your developers have to wait for a long time before trying the code changes that they have just coded? I remember 5 years ago a project that the build and deploy of the application spent 13 minutes and 21 seconds.

Time wasted

If you multiply this time by the number of builds per day that a developer can do that’s, 801 seconds * n builds = 801 * n seconds = 0.2225n hours per day. If you multiply 0.2225*n * 20 days * 12 months = 53.4n hours per year that are wasted because of an slow build process which is 6.675*n unproductive days per year for this developer.

In the following chart you can see the number of days wasted considering the number of deploys per day.

If n=15 then the number of days wasted per year is 100 (100/(20*12) -> 41% of work days in a year)

You can go to google to plot it in the following link Plot 6.675x

We are not considering other factors that decrease the productivity of the developer that during this time that he is waiting, he starts doing other tasks losing the focus on what he was doing.

Add the hourly pay rate that you pay to your developers and that’s some money.

6.675 * n * num_devs_in_company * hourly_pay_rate = money = time

If the build spends a lot of time possibly it’s because you have to compile a lot of code and if you have a lot of code maybe you have a big application that should be split into smaller pieces to reduce the build time and create small services that nowadays are called microservices.

Saving time

All that saves time, is something good. It’s impossible to reduce the time of build to 0 seconds but keeping your build and deploy fast should be something to consider while you work in software development.

In my team I have to develop software in different software modules and we try to keep it simple and fast to build and deploy. One thing that we did was to create a maven profile that everytime a clean install is done locally, it copies the ear automatically to the deployment folder of the JBoss using the JBOSS_HOME environment variable and using the maven-antrun-plugin

        <profile>
            <id>deploy-jboss-64</id>
            <build>
                <plugins>
                    <plugin>
                        <artifactId>maven-antrun-plugin</artifactId>
                        <executions>
                            <execution>
                                <id>deploy-DU</id>
                                <phase>install</phase>
                                <goals>
                                    <goal>run</goal>
                                </goals>
                                <configuration>
                                    <tasks>
                                        <copy overwrite="true" file="target/${project.artifactId}.ear"
                                              todir="${env.JBOSS_HOME}/standalone/deployments"/>
                                    </tasks>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>  

This saves time to me (and to the other developers that develop in the same module) everytime that I have to deploy a new version of an ear file in my local JBoss. Otherwise I have to manually copy the ear resulting from the build into the deployments folder of the JBoss.

Conclusion

All this leads me to think that in an organization it’s important to concienciate everybody, a team or at least one person to check what improvements can be made in order to speed up the build and deployment processes. All this time could be dedicated to implement new products or services that could bring value to your organization. This is what is called the cost of opportunity and it applies to your work life and also to your personal life.