The One Line of Code Process

There’s a process improvement approach that I like to use to help reduce the friction for a development team to deliver software. Since I’m a fan of “it’s not done until it’s running in production,” reducing the friction to get software to production is a pretty big deal. So, I analyze the “one line of code” process.

It’s a simple question: what is the process to get a single line of code change into production? That includes, of course, writing the line of code, but it also includes source control, building the software, testing it, and deploying it (and potentially other tasks, as well).

I focus on a single line of code in order to simplify the conversation that I have with the team. I recognize that the process might be slightly different if there’s more code involved, but the idea is to see the basic steps. Each step has some amount of cost, whether in time, money, or complexity.

The approach is fairly simple. I get the team together and talk them through the steps necessary to go from a simple change in the code to getting it deployed into production. Then, we walk through those steps and justify each and every one. For each step in the process, I ask questions like the following:

• Why do we need to do this step?
• Does doing this step reduce the likelihood of a bug escaping into production?
• Is this step worth the cost?
• Can this step be automated?
• What would happen if we didn’t do this step?
• What was the original reasoning for performing this step and is it still a good reason?

These questions get asked because the goal is to potentially do the following things:

• Simplify or reduce the cost of the process (both in time, money, and complexity) by removing process steps that aren’t worth it.
• Automate steps to reduce the chance of human failure and reduce the friction associated with completing changes to the software.

Here’s a sample process that may capture some of the steps typically used by an Agile development team making a change to a website. Note that it’s helpful to identify steps that can be done in parallel, as well as those steps which are fully automated (meaning, they are triggered and run without human interaction) or partially automated (meaning, they are manually triggered, but run without human interaction).

1. Write the line of code. [manual]
2. Write applicable unit tests to verify the change or addition. [manual]
3. Build and manually verify the change on a local developer’s computer. [manual]
4. Create a pull request (PR) in source control. [manual]
5. Request that fellow developers review and comment on the PR. [manual]
6. Make changes based upon the review. [manual]
7. Deploy the change to a shared development environment. [partially automated]
8. Manually test the change in the environment. [manual]
9. Show the product changes to the product owner. [manual]
10. Merge the changes into a shared branch in source control (e.g. release branch). [manual]
11. Deploy the changes to a test environment. [partially automated]
12. Notify the Quality Assurance team to test and verify the change and run regression tests. [manual]
13. Schedule the production deploy and release. [manual]
14. Deploy and release to production. [partially automated]

How does the above process compare to the process your team is using? Can you see where steps could be simplified, removed, or automated?

To be fair, some of the steps won’t be able to be removed or automated, such as writing the code. You may even have regulations that prevent you from making certain kinds of adjustments to the process. However, even the sample process above can be simplified and improved significantly (that is, technology exists to automate much of it).

What I’ve found with this process, beyond just reducing the friction for the team to deliver software changes, is helping the developers (and other stakeholders) think differently about developing and delivering software. If your team is already doing Continuous Deployment, then this process improvement approach may not be of much value, but if they are not, then this may help your team produce higher quality software, faster.