03 The Change Factor, 04 Breaking Change

Throughput of Change: Maker of Bottlenecks

Reading Time: 6 minutes

In the previous chapter, we talked about Bottlenecks and had our first impression on its place and effects on our development workflow. To understand the concept of it, we inspected our deployment. We’ve seen how a manual deployment is a Bottleneck only when there is something to do about it. We’ve then seen how automation removes it.

Only once removed, we could have looked back at it to see a Bottleneck’s effect. It affects our engineers and our workflow, even ending up speeding our application’s evolutionary processes towards a Bundle and a Monolith. Both of which cause Inefficiencies on their own.

We’ve finished the chapter by recalling that deployment is only one step, not even the final step, in our development workflow. There also are coding, code review, building, unit tests, integration tests, end-to-end tests, deployment, monitoring. All of which are a part of our workflow and each one can be a Bottleneck on its own.

In this chapter, we’re going to see what connects these steps and how they affect one another. And we’re going to do so by removing Bottlenecks. Because they are everywhere.

Practicing Bottlenecks

Let’s imagine we are a single engineer working only on our single application. We might be doing so alone in our garage in a stealth mode startup or we might be doing so in the darkness of a cellar of a large multinational enterprise.

One day we woke up in the morning and we got fed up with manually deploying every day. It takes us about 30 minutes and it is error prone. We coded a little bash script to make it more reliable, and we’d be avoiding future Instabilities and Inefficiencies.

But in the present time it still takes 30 minutes to run, during which we can not touch our workstation. As we had enough of sitting and staring at the screen, we started running this script from a remote server in our cloud. We’ve made some adjustments to it and it automatically pulls our latest code from the main branch. As our deployment is running in the background, our workstation has become free. We can code the next task during deployment. Our first Bottleneck removed, and an immediate Inefficiency removed as well. A few days later our colleague helped us run our script from Jenkins and we realized we’ve just made our first Continuous Deployment pipeline.

We’ve gained at least 30 minutes of coding per day. If we won’t use it for a good nap, we can reinvest it back into coding the next task. Presuming we are coding for 8 hours a day, that’s a 6.25% increase to our coding time. An additional whole coding day per month, and a lot of coding can be done in a single day. We have increased our work Throughput, the result of removing a Bottleneck.

In our simplified and imaginary development workflow, one step prior to deployment is coding. Let’s take the practice of running scripts remotely and see how it relates to coding. At RapidAPI (2021) not all engineers knew of it. Some were running data migrations, analytics and other frequent tasks against our production systems, from their own workstations. When they were doing so from home, it had exhausted their network bandwidth. While running, they could do nothing but stare. Our lack of practice was a Bottleneck. Once we’ve set up remote servers in the cloud for everyone, those who practiced it could code while the scripts are running in the background. They had increased their Throughput quite immediately. The exact same reason and outcome we get when we strengthen our coding practice itself, through katas.

Engineers have many more practices to learn, such as many practices to learn such as TDD & BDD in a CI pipeline, avoiding execution of non-beneficial tasks, and having beneficial monitoring and tracing capabilities. Is it possible for a single engineer to double his Throughout? I really hope so, otherwise we would all stay juniors forever.

Back Pressure

Our development workflow has an incoming rate. Our engineers are not making Changes out of nowhere, but out of a Cause. In our company also exists a Product Manager who creates User Stories (Causes), and she does so at a constant rate of 5 per month. Our entire development workflow, based on its steps and existing Bottlenecks, has a consumption rate of only 4 per month.

As there is a gap between the incoming rate of our development workflow and its consumption rate, a stockpile is created. There would be at least one User Story per month that would be left undone. This stockpile is better known as the Backlog. The result would be a less happy Product Manager and less satisfied customers.

Due to Bottlenecks, our development workflow is having a hard time keeping up with the required Changes. The effect they have is a Back Pressure, a push back to our product managers and to our company’s business results. Because our development workflow is only a part of our company’s workflow. The separation between product and engineering is an artificial one.

Within our development workflow, we had actually already seen the Back Pressure effect in the previous chapter. It has resulted in speeding our application’s evolutionary processes, causing our engineers to bundle together multiple Changes, because our deployment was a Bottleneck.

As Bottlenecks are removed, we increase our Throughput and the Back Pressure eases. We would be making our Product Manager happier. Unfortunately for him, that might turn our Product Manager into a Bottleneck. Not that he has done anything wrong, he is a part of the company’s workflow. He is the input to the development workflow, not separate from it thus affected by it. All a part of a process we called The Force of Change, and it is full of Bottlenecks. Such as our architecture and organization structure.

[Both Product Managers and Engineers can better practice and control Change by reading Projection, the third book about the importance of the Change/Feedback cycle, short and long term planning/execution, breaking down tasks and user stories, estimations and much more]

We must not forget there is another way to increase our Throughput, by hiring. We can hire more Product Managers to increase their Throughput. If our development workflow has no more Bottlenecks and we still need to increase our consumption rate, we can hire more engineers.

On the contrary to some common thought, scaling personnel is unlike scaling servers. If we buy another server, we indeed double our resources. When it comes to personnel and prince’s law, their Throughput would not linearly increase, but with a factor of square root.

Effectively removing a Bottleneck for sure increases our Throughput. But increasing our Throughput does not go without consequences. It may create an Upstream Pressure on our workflow, uncovering and creating more Bottlenecks. In the next few chapters, we’re going to uncover those by performing a split on our single application.

Leave a Reply