You may have heard the phrase "do what's painful more often" applied to software development practices like deployments and code reviews. The logic seems to be: if it hurts, avoid it. But counterintuitively, delaying inevitable discomfort often makes things worse.

If deployments are scheduled weekly, bi-weekly, monthly, or quarterly, the pain will be directly proportional to the work associated with those deployments.

For a single individual, it may be manageable for a week, but if an entire team's worth of work is associated with that deployment, the variables to consider and manage become almost exponential.

If a team is deploying every two weeks or within their sprint cadence, the amount of code to review, merge, and deploy without conflicts or critical errors can be near impossible.

Imagine a scenario where the amount of effort to do a bi-weekly deployment is roughly eight hours for the entire team to merge code, resolve conflicts, and deploy hotfixes to stabilize the deployment.

One option would be to move to monthly deployments. Since the deployments are so painful, and doing it every two weeks is a severe time sink and distraction, moving it to a month would reduce the frequency of that distraction and time sink.

In reality, delaying the painful experience will only make it worse. The variables that made it painful weren’t the fact it was a deployment or a code review but the amount of code in that review and deployment. The more code, the more pain. The more disparate branches that need to be merged, the more chances of merge conflicts.

Delaying the frequency increases the code, the number of branches, and the complexity and possibilities for failure.

If delaying makes it worse, then the frequency must be increased. How frequent? Well, the more frequent, the better. But how does an organization go from bi-weekly, monthly, to “more frequent”? And what’s a good frequency?

The frequency almost doesn’t matter as long as it’s shorter than what was happening before, and critically, the goal is to continue to shorten that frequency.

Instead of avoiding the pain, increase deployment frequency. Start by shrinking the interval, say from monthly to biweekly. As processes prove inadequate under higher frequency, address those bottlenecks. Shift from biweekly to weekly, then daily, then multiple times per day.

This forcing function exposes flaws and drives automation and process improvements. To deploy multiple times daily, organizations must reevaluate everything to identify bottlenecks. A hint for finding a bottleneck will be the amount of work piled up in front of it or how long the work is waiting to be processed.

Here are some constraints to consider.

1. Ticket creation, the definition of ready, acceptance criteria, and ticket sizing using story points.
2. Trunk-based vs. Git flow repository management. How easy is it to merge code back into production?
3. Testing Automation: Unit tests, integration tests, end-to-end tests. Are tests part of the definition of done or the acceptance criteria? Do tests run locally every time the code is saved, the code is added to a pull request, and every time the code is merged? Are tests running against production?
4. Code Reviews - Can it be automated? Linters, security checks, etc.? Can Pair coding be used to ensure code quality?
5. QA - Is there manual testing that needs to happen, or can test coverage cover it? What if there is an error in production? How quickly can it be rolled back? What’s your time for recovery?
6. Deployment - is this happening as part of the DevOps pipeline, or is the deployment ability limited to specific individuals? What value does restricting it provide? What value does allowing all developers to deploy provide?

The key mindsets:

• The business goal is to deliver customer value.
• More frequent delivery provides faster feedback and learning.
• Identify and fix bottlenecks restricting your throughput.

The same logic applies to the rest of a business. Find the pain points central to your core competency. Resist outsourcing them. Increase frequency to surface constraints. Address bottlenecks limiting your ability to deliver value.

Discomfort is growth trying to happen. Don't avoid necessary change and learning. Embrace frequent discomfort to continuously improve.