Understanding the Economics of Software Delivery

The increasing recognition of the importance of these is part of what originated the DevOps movement, which correctly identified the segregation of “Development” (writing the application) and “Operations” (running the application) as a source of issues.

One of the most important practices to arise out of this movement is Continuous Delivery, the automation of the software delivery process; by automating, teams improve the reliability and speed of releases and simultaneously, reduce the overhead involved. This, in turn, enables them to deliver more often, which provides more and better feedback.

Why and how does Continuous Delivery work, though? To understand this, we need to learn about the economics of Software Delivery; in this post, we’ll write about Deployment Overhead.

The process of delivering a piece of software from source code to production (whatever that means) involves a number of activities:

• Packaging the application

• Installing the package in the runtime environment

• Testing

• Configuring the application

• Migrating application data

These operations are not, strictly speaking, adding value to the software: you can repeat them as often as you like but you’re not going to get new features in the software unless you actually change the source code. Moreover, these still take time, which you won’t be ablo to use for value added development tasks; for this reason, we call these activities deployment overhead.

Now, imagine that it takes you an hour to do all of these1: if you want to release every day and you have 8 hours of work in a day, that leaves you with only 7 hours to work on code, i.e., your productivity is

In other words, only 87.5% of your time was spent adding value to your product.

However, what happens if, instead of doing this every day, you do it every 2 days (16 work hours)? Your productivity is now:

Wow, you just got a 6% gain in productivity! Maybe we’re on to something: by releasing less frequently, we can increase our productivity…

Indeed, this is true; plotting deployment overhead as a function of the release cadence (the inverse of frequency) makes it easy to spot the trend:

This seems to suggest that batching up more changes for each deployment is more efficient and thus makes the most economic sense.

In this article, we have started to describe the economics of software delivery, starting with Deployment Overhead and how, taken in isolation, it suggests that it’s best to release infrequently, in order to be more efficient.

However, deployment overhead is not the only variable that influences the economics of software delivery; as we’ll see in upcoming articles, other concerns will come into play that will push us into shorter deployment cadences.