What Are Inner and Outer Loops?
The Inner Loop
The inner loop includes all the activities directly related to creating the product. This is where the magic happens — coding, building, and unit testing. Developers thrive in this zone because it’s where they can be the most creative and productive. It’s all about building the features, fixing bugs, and writing tests that make our applications work.
The Outer Loop
The outer loop encompasses the necessary but often tedious tasks required to push the code into production. This includes integration, integration testing, releasing, and deployment. While these tasks are essential, they are generally seen as chores by developers. They don’t generate direct value and often interrupt the flow of inner-loop activities.
Maximizing Inner Loop Time
From both a productivity and personal satisfaction standpoint, maximizing the amount of time developers spend in the inner loop is crucial. When developers can focus more on coding and less on administrative tasks, they are happier and more productive. It’s like having a chef spend more time cooking delicious meals rather than washing dishes.
Reducing Outer Loop Friction
Outer-loop activities, while necessary, often slow down the development process. By minimizing these interruptions through better tooling and automation, we can help developers spend more time in their creative zone. Think of it as automating the dishwasher so the chef can keep cooking up a storm in the kitchen.
Platforms as enablers
As the left side of the diagram shows, the loop across deploying software, detecting its operational characteristics (or usage metrics), and correcting them, spans two organizational units whose opposing incentives pit them against each other. Often referred to as the “outer loop” of software delivery (the “inner” comprising the code/test/debug), modern software approaches like continuous integration place higher demands on making the outer loop spin faster and with less friction. In a traditional organizational model, the outer loop crosses organizational boundaries and inhibits these new ways of working.
Placing operational responsibilities in the development team, thus avoiding the organizational boundary, is one way to reduce this friction. This “you build it, you run it” model does indeed align the incentives into a single team, but it also burdens that team with a broad set of tasks and responsibilities. This means that cognitive load for teams increases (every developer now must also be a cloud and ops specialist) or team members will specialize (some folks are ops-heavy and others dev-heavy), which essentially reverts the state of affairs to the starting point, just under a common team label.
Placing operational responsibilities within the development team is the correct setup, but those teams must have the matching tools to perform these tasks as efficiently as possible. That’s where platforms come in. Developer/engineering productivity platforms can be depicted as the axle that helps the outer loop spin faster.
A platform team builds the axle that makes the outer loop spin faster. But it’s not part of that loop, because it’d be bound to become a bottleneck. The platform team is part of another loop, though: the loop that takes input from development teams to evolve the platform. This loop spins much more slowly and does not directly affect the delivery teams’ velocity.
Sources:
Leave a Reply