When adopting DevOps, many organizations focus on increasing the speed of software delivery and deployment without ensuring that they have adequate breaks in place. As a result, instead of reaching the promised benefits of DevOps, these organizations often end up “hitting the wall.”

𝗪𝗵𝗮𝘁 𝗱𝗼𝗲𝘀 𝗮 𝗿𝗮𝗰𝗲 𝗰𝗮𝗿 𝗹𝗼𝗼𝗸 𝗹𝗶𝗸𝗲?

When this question is asked, many think of sleek car designs, powerful engines with immense horsepower, and smooth-shifting gearboxes. Since race cars imply speed and acceleration, it is perhaps natural that such features come to mind directly

However, race cars also have high-performing braking systems, often more powerful and superior to those in standard consumer vehicles. The braking system allows the car to maneuver around corners securely, decelerate when turning, and stop safely when needed. Just imagine the consequence of the brakes not being appropriately adapted. Would anyone dare to hit the gas pedal if they had all other race car features?

Therefore, contrary to many beliefs, 𝘁𝗵𝗲 𝗺𝗮𝗶𝗻 𝗯𝗲𝗻𝗲𝗳𝗶𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗯𝗿𝗮𝗸𝗶𝗻𝗴 𝘀𝘆𝘀𝘁𝗲𝗺 𝗶𝘀 𝘁𝗵𝗮𝘁 𝗶𝘁 𝗮𝗹𝗹𝗼𝘄𝘀 𝘆𝗼𝘂 𝘁𝗼 𝗴𝗼 𝗳𝗮𝘀𝘁𝗲𝗿! In addition, 𝘁𝗵𝗲 𝗳𝗮𝘀𝘁𝗲𝗿 𝗮 𝗰𝗮𝗿 𝗶𝘀, 𝘁𝗵𝗲 𝗺𝗼𝗿𝗲 𝗮𝗱𝗲𝗾𝘂𝗮𝘁𝗲 𝗯𝗿𝗮𝗸𝗲𝘀 𝗶𝘁 𝗻𝗲𝗲𝗱𝘀.

The exact relation between cars’ brakes and speed can be applied to 𝗗𝗲𝘃𝗢𝗽𝘀. For many software development organizations, DevOps is about “speed and acceleration,” leading to quick market time, short lead times, and frequent software deliveries. Thus, these organizations see DevOps practices such as continous integration and delivery (CI/CD) as the “gas pedal” for faster delivery and deployment. While this is true, many organizations often underestimate – or even neglect – the need for an adequate DevOps braking system that allows for increased acceleration and speed to be reached.

𝗪𝗵𝗮𝘁 𝗺𝗮𝗸𝗲𝘀 𝗮 𝗗𝗲𝘃𝗢𝗽𝘀 𝗯𝗿𝗮𝗸𝗶𝗻𝗴 𝘀𝘆𝘀𝘁𝗲𝗺?

The DevOps braking system is made of 𝘁𝗵𝗲 𝗳𝗲𝗲𝗱𝗯𝗮𝗰𝗸 𝗹𝗼𝗼𝗽. The evolution of the feedback loop needs to be tightly coupled with the speed of software deliveries and deployment. To illustrate this, let’s assume that a software-as-a-service organization deploys a new software release once a month to its production system. While the organization monitors the production environment continuously, the average time it takes to resolve a software bug is 3 weeks (including time to detect, respond, and repair).

Thus, if the organization considers accelerating the delivery and deployment cycle to one month, it must first ensure that the average bug resolution time is reduced to 2 weeks or less before attempting the acceleration.

𝗧𝗵𝗲𝗿𝗲𝗳𝗼𝗿𝗲, 𝗶𝗳 𝘆𝗼𝘂 𝘄𝗮𝗻𝘁 𝘁𝗼 𝗴𝗼 𝗳𝗮𝘀𝘁𝗲𝗿, 𝗺𝗮𝗸𝗲 𝘀𝘂𝗿𝗲 𝘁𝗼 𝗵𝗮𝘃𝗲 𝗮𝗻 𝗮𝗱𝗲𝗾𝘂𝗮𝘁𝗲 𝗯𝗿𝗮𝗸𝗶𝗻𝗴 𝘀𝘆𝘀𝘁𝗲𝗺 𝗳𝗶𝗿𝘀𝘁.

What happens in many organizations is that they often attempt to increase the speed of deliveries without ensuring there is a proper feedback loop in place. As a result, after a short period of acceleration, the organization often realizes that things have gone out of control, which can be realized with stressed developers juggling multiple tasks simultaneously, unsatisfied customers, and more complaints.