“A ship in harbor is safe, but that is not what ships are built for.”– U.S. Navy Rear Admiral Grace Murray Hopper
If you’re talking about highway driving, going slower is safer. The Insurance Institute for Highway Safety found that raising speed limits increased the rate of highway deaths.
That is not the case for software releases.
A false dichotomy exists between going fast and being safe. Much like other falsehoods (like the notion that the human tongue has five taste zones or that we use only 10 percent of our brain’s power), the idea that fast and safe are polar opposites is a lie. DevOps Research and Assessment (DORA) has proven year after year that there is a high correlation between the success of first-time deployments and the number of releases to production. As it turns out, doing something over and over leads to doing it better. Go figure.
[ Some common DevOps wisdom falls flat. Read 7 pieces of contrarian DevOps advice. ]
The military conducts constant drills that mirror real-world events. That’s why war-gaming is so important in the military. When military members practice, they constantly improve and perform at a higher level in the theater. Of course, ships are much safer in port, but that’s not what they are built for. By exercising drills and building “muscle memory,” military leaders have confidence their teams will perform better when needed.
Software releases should not be any different. Here are three critical reasons to take your foot off the software release brake:
1. Success metrics all focus on deployments
DORA uses four metrics to evaluate the success of a company’s software delivery process: deployment frequency, lead time for changes, time to restore service, and change failure rate. Notice that these metrics all focus on when and how the software is released to production.
Development and test environment deployments are not counted; only production deployments matter. Furthermore, failure is expected. The measurement that matters is how quickly a company corrects course. By focusing on these metrics, companies can have a far better understanding of how quickly they are performing and how they compare to their peers.
[ Read also: DevOps metrics: Are you measuring what matters? ]
2. Once per month releases are not enough
When soldiers do not perform to standards, bad things happen. To that end, the military seeks to have all soldiers perform as a unit. Thus, the first thing they learn in boot camp is marching in cadence. Similarly, by having a regular cadence of software releases, companies can have confidence that the team is acting as a unit and will deliver the expected results.
On the flip side, if a company releases once a month, engineers must rely on run books (a DevOps anti-pattern) and tribal knowledge to perform the release. If people leave the company, the engineers must rely on outdated run books.
Allowing for speed in software releases also allows for business agility and experimentation. If a company has a 10 percent success rate for new ideas, the faster those ideas can be tested, the higher the number of successes. If you are releasing once a month, you’ll be lucky to have one success a year. That is beyond disheartening.
3. Maintaining speed is easier than gaining speed
Another analogy that builds on this idea is train efficiency. Freight trains are very heavy and require a lot of energy to reach speed. However, the amount of energy required to maintain speed is very low.
The same is true with your car. Notice the RPMs when you accelerate on a highway, and the drop once you reach cruising speed. Releasing software should be similar. The amount of energy to put automation in place is great, but the benefits become obvious when the number of releases increases and the mean time to recover from failure plummets alongside an increase in first-time success rates. Thus, moving fast leads to higher efficiency.
Bottom line: Go fast to go safe
Of course, many people in your organization will not trust this approach. They still believe in the safety net of a person manually making changes. They believe that a person can respond to failure quickly and make the right decision. I believe that this only encourages reactive work and does not engender a culture of innovation. In fact, it results in technology stagnation.
When companies prioritize speed, velocity and quality increase. When quality increases, so does safety. But for this to happen, companies must commit to organizational change and incent siloed teams to work together. Otherwise, companies can expect the same results that Sears experienced: slow, ponderous decision-making that leads to bankruptcy.
[ Read also: Teaching an elephant to dance - free EBook on leading digital transformation. ]
