Join me as I share insights and discoveries from my journey in the world as a software engineering manager by day and tinkerer by night.
13 December 2022
Many of us think that we are moving too slowly and that our processes take too long. We started to measure how long our finished code idles around as a pull request, tracking the lead time over certain periods in the hopes that we can be faster. The process of creating pull requests, collecting feedback and iterating on code has become second nature to most of us and isn’t even questioned anymore. But what if there was another way that would allow us to go out there and release faster?
An alternative approach is described by Rouan Wilsenach in his article: “Ship / Show / Ask”. The idea is to have a different branching strategy than what most of us are currently using. Different types of code changes are separated in the strategy and not put into a “one-size-fits-all” approach as most of us are currently doing.
The first category of code changes falls into the “ship” category. You simply commit it directly onto your main branch! No separate branch, no PR, no feedback. This could be fixing a simple bug, updating documentation or simple, small changes that introduce minor changes to the codebase. Your first instinct might be: “Wow, this is really dangerous!”, but our continuous integration strategy provides your safety net, running all the checks on the code before it makes it into production.
This second category works pretty much like we know it: we create a branch and a pull request so that the team is informed about the changes that are happening. By creating a PR you open up the opportunity for your team members to comment on the code you have written. However, you are not waiting for them to approve your code! You simply merge it. The strategy is appropriate if you want feedback on how you could have done things better, but you want to release quickly. It also works if you want to demonstrate how you solved a problem in the isolation of a PR, because you used a novel pattern or are proud of the way the problem has been solved in such an interesting way. Here you are focusing on learning for the team while still delivering fast.
This third category works exactly the way we are used to: we create a PR and we pause to get feedback on it from our colleagues. We discuss the feedback in the PR and possibly iterate on the implementation. This is the workflow that Github excels at and emphasizes. We are all very familiar with it. This approach is when you really need feedback from your colleagues because you are unsure of the changes you have introduced. This may be because you are not sure if it works. You are not 100% familiar with the system you are working in or are afraid that you will introduce side effects to other parts of the system or other systems. Maybe you know that the code you have written is not the greatest of all time and you actively seek feedback on how to make it better.
What do you think? Should we ask less and ship more? It might be a wise idea to show more at the beginning and slowly build trust within the team that “ship” just works. Getting feedback about how to implement something before starting the code editor or pairing during the implementation would also be a helpful way to be more confident in shipping. Please refer to the linked article for even more food for thought on this.