The inner loop is the iterative process that developers perform when they write, build, and debug code. There are, of course, other things that a developer does, but the inner loop is the core set of steps that developers perform over and over before they share their work.
Exactly what goes into each developer's inner loop depends on the technologies they work with, the tools they use, and their own preferences.
For example, if you're writing a C# library, your inner loop might include coding, building, and testing. If you're doing web development, your inner loop might include coding, bundling, and refreshing your web browser to see your progress.
The following illustrates these two types of inner loops:
Each of these loops might include a fourth step, where you commit and integrate your changes with the team's central repository, for example, on GitHub.
In reality, most codebases consist of multiple moving parts. The definition of an inner loop on any single codebase can vary, depending on the project.
Which steps in the inner loop add value?
In
Assess your existing software development process , you and the A team learned how a value stream map (VSM) can help you analyze your current release cycle process. Like the team's VSM, you can measure your inner loop to see which parts have value to the customer and which parts are eating up time without producing any value.
You can group the steps within the inner loop into three broad categories: experimentation, feedback collection, and tax.
In the example of building a C# library, here's how you might categorize each step:
Of all the steps in the inner loop, coding is the only one that adds customer value. Building and testing code are important, but ultimately you use these as tools to gain feedback about whether the changes provide sufficient value. For example, does the code compile? Does the feature satisfy the requirements? Does the feature work correctly with other features?
A tax defines work that neither adds value nor provides feedback, but is still necessary. In contrast, you can categorize unnecessary work as waste and then eliminate that work.
How can I optimize the inner loop?
Now that we've categorized the steps within the inner loop, here are some general statements that we can make:
- The activities within the inner loop should happen as quickly as possible.
- The total loop execution time should be proportional to the changes that you're making.
- You should minimize the time it takes to collect feedback, but maximize the quality of the feedback that you get.
- You should minimize the tax you pay by eliminating it where it isn't necessary. For example, commit your changes only after all tests pass.
- Remember that, as the size of your codebase grows, so does the size of the inner loop. For example, having more code means you need to run more tests, which in turn slows down the inner loop.
If you've ever worked on a large, monolithic codebase, it's possible to get into a situation where even small changes require a disproportionate amount of time to execute the feedback collection steps of the inner loop.
There's no single solution that ensures that your inner loop is optimal. But it's important to notice a slowdown when it happens and to address what's causing it.
Here are a few things you and your team can do to optimize the inner loop:
- Only build and test what changed.
- Cache intermediate build results to speed up full builds.
- Break up the codebase into smaller units.
You can gain immediate benefits by implementing the first two recommendations. However, use caution when breaking your codebase into smaller units. When done incorrectly, breaking your codebase into too many small units can have the opposite effect: a tangled loop.
What are tangled loops?
A tangled loop happens when multiple processes, each with its own inner loop, become dependent on one another.
Say that your monolithic codebase has some set of core functionality that does much the difficult work your application needs to perform. You might package that code into a helper library.
To do this, you would typically move your library code to a separate repository and then set up a CI/CD pipeline that builds, tests, and packages the library. The pipeline might then publish the result to a package server. You would then configure your application to pull that library from the package server.
Development of the library code forms its own inner loop. When you make changes to the library and, for example, submit a pull request to merge your changes, you transition the workflow from the inner loop to the outer loop. The outer loop includes anything that depends on your library, for example, your monolithic application.
Initially, you might see some benefits. For example, you might see decreased build times in your application because the library code is already built for you. It's likely, though, that you'll need to develop an application feature that requires new capabilities in the library. This is where teams who have incorrectly separated their codebases start to feel pain.
When you evolve code in two separate repositories where a dependency is present, then you'll probably experience some friction. In terms of the inner and outer loops, the inner loop of the original codebase now includes the outer loop of the library code that was previously separated out.
Outer loops can include taxes such as code reviews, security scanning, package signing, and release approvals. You don't want to pay that tax every time you add a function to the library that your application needs.
In practice, this situation can force developers to work around processes or code in order to move forward. Such workarounds can build up taxes that you'll have to pay at some point.
This doesn't mean that breaking code up into separate packages is a bad thing. You just need to carefully consider the impact your decisions have on the outer loop.
