The term “silver bullet” comes from a 1986 paper by Frederick Brooks. He is the author of the book “The Mythical Man-Month”, which discusses the development of IBM’s OS/360 operating system. He led this project. It had a budget of $5 billion and in the sixties was second only to the moon landing. The book contains insights that are still important today - for example, that a project becomes slower at first if you add more people to the project, because the people first have to familiarize themselves with the project.
Silver bullets are actually used to hunt werewolves. Brooks argues that many IT projects eventually mutate into monsters and we need silver bullets. But there is no such thing as a silver bullet: In his opinion, no single development in a decade promises an order of magnitude better productivity, reliability, or simplicity. An order of magnitude is a factor of 10.
Brooks argues that technical complexity drivers have already been eliminated. But if most of the complexity now comes from the requirements, designs, and tests, you can’t just solve the complexity with a simple trick. He thinks buy instead of build is promising as are better handling of requirements, “growing” software through incremental development, and finally good designers.
Continuous delivery refers to the continuous delivery of software. It is clear that a higher deployment frequency reduces the time it takes for a change to go into production. There is now a study (“2018 State of DevOps Report”) that shows further effects. It distinguishes between “Elite Performers”, who deploy several times a day as needed, and “Low Performers”, who deploy between once a week and once a month. Teams with quarterly releases are therefore not even “low performers”. Elite performers obviously achieve higher speeds with which changes enter production:
The deployment frequency is 46 times higher.
The time it takes for a change to go into production is 2555 times less.
But there are also other positive effects:
The probability of deployments failing is seven times lower.
2604 times faster restart after service failure.
2/3 more working time can be spent on new features.
Half as much working time can be spent on security problems or defects reported by end users.
It only takes a third of the time for customer support.
So productivity and reliability increase. Continuous Delivery could therefore be a “silver bullet”, although according to Brooks such thing should not exist. How can this contradiction be resolved?
One explanation could be that Brooks is not right. To prove that something does not exist is difficult in principle. His paper does not give any evidence, but essentially reflects the opinion of the author. It is now 30 years old, so perhaps something has changed in the meantime.
On the other hand, Brooks is very experienced and one of the most important people in the software development scene. So you can’t just ignore the paper.
Continuous Delivery - Just a Hype?
The DevOps study could also be flawed. Behind the study is Gene Kim, who among other things wrote the DevOps manual and the book about the Phoenix project. Both are books that praise continuous delivery. Another author of the study is Jez Humble, one of the authors of the first Continuous Delivery book. It would be quite a surprise if these people wrote a study that shows that continuous delivery doesn’t bring significant benefits.
But the third author in the group is the scientist Dr Nicole Forsgren. So you can be sure that the study will withstand a scientific review and has been evaluated according to scientific standards. And finally, the study has a large database: A total of 30,000 people took part in the study. A large database and a professional evaluation of the data actually leads to meaningful results.
Both are True?
I don’t think there is any contradiction. The study and Brooks are both right. There are several reasons for this:
Increasing deployment speed is not a “single development”. For speeding up deployment, configuration management, testing, deployments, and approval of changes must be automated. This is also shown by the study. Often the changes even impact the architecture. Only small, separately deployable units such as microservices can be realistically deployed several times a day. Higher deployment speed can therefore uncover the next bottleneck and therefore the challenges that need to be solved in order to deploy even faster. But it is not a “single development”, it requires a multitude of measures.
Brooks rules out an order of magnitude improvement in productivity, reliability or simplicity. However, the study sees “only” by a factor of 2/3 in productivity if the time spent on new features is used as a measure for new features. In terms of reliability, it is a factor of two if you consider the amount of time it takes to eliminate errors. The probability that a deployment will lead to an error is six times lower - but that’s not an order of magnitude, either.
Finally, Continuous Delivery implements Brooks' recommended “growing” of software: software is brought into production more often. Therefore, the teams proceed in smaller steps. This favors feedback cycles: results from production can be immediately incorporated into development and the project can grow step by step instead of being completed according to a complex plan.
Continuous Delivery actually has many distinct advantages. The study shows them clearly and explains them very well. This helps to clearly demonstrate the advantages of Continuous Delivery. However, Continuous Delivery is probably not a silver bullet, either. Nevertheless, the advantages of continuous delivery go far beyond the fast delivery of software and new features. It is therefore worth investing in this area, even if features do not have to be brought into production faster, because productivity and reliability also improve significantly.
Silver bullets are supposed to improve software development by at least one order of magnitude, but unfortunately there are none. However, continuous delivery has demonstrable significant benefits for reliability and productivity.
Header photo by Mitya Ivanov on Unsplash.