Smaller, more frequent batches of changes to code, either app/service functionality, fixes, or configuration, help teams simplify diagnosis of issues while doing these things in any environment, not to mention when finally releasing to production.
Planning, developing, packaging, deploying, testing, and releasing gets far more complicated the more changes are encapsulated in the ‘batch’ of work being delivered. The more there is to review, test, deploy, and monitor, the harder it is to know exactly which component or change is at fault when issues are encountered.
Smaller, more frequent batches of changes to code, either app/service functionality, fixes, or configuration, help teams simplify diagnosis of issues while doing these things in any environment, not to mention when finally releasing to production.
Working this way helps developers catch and fix errors faster and earlier in implementation cycles. Though pinpointing the source of issues takes more than just smaller batches of work, it certainly helps. It also helps to have proper observability practices, the right tools in place, and processes that are focused on ensuring the correct level of feedback and quality while also minimizing the amount of time it takes to follow them.
Small batches also often improve and accelerate collaborations between team members, encouraging everyone to stay pointed towards the same goals. Pull requests (PRs) that are junked up by a dozen or more seemingly unrelated file changes take much longer to review that clean, clear, and well-commented PRs.
This pattern also lends itself to Trunk-based development, continuous integration (CI) of code into a single source of truth that is always tested and shippable. As Martin Fowler says related to CI:
“If a clash occurs between two developers, it is usually caught when the second developer to commit builds their updated working copy. If not the integration build should fail. Either way the error is detected rapidly.”
At a higher level, small and frequent code changes help to reduce the risk of project failure. When changes are made in small increments, it becomes easier to identify and mitigate any risks that may arise. This can help to ensure that projects are delivered on time and within budget, and that they meet the needs of stakeholders.
As many Agile practitioners have realized over the years, finding an optimum batch size is a tricky business. Principle #6 of the Scaled Agile Framework (SAFe) discusses reducing batch sizes in length. Most teams usually have room to improve in this area, even if they have concertedly done so in the past; there is always some fat to trim.
It’s very easy to slip into the ‘just one more’ fallacy when you’re coding or changing configuration, especially when the process to get it working or test it out takes longer than patience affords. The problem that forms from this anti-pattern is that things can easily get missed when aiming for multiple targets. Teams that put controls and cultural norms in place to avoid unnecessarily bulky batches end up with more maintainable and understandable code bases, better auditability, and testability often built in.
Small, frequent code changes and work batches can lead to higher quality software and processes for several reasons. They help to catch errors more quickly, encourage collaboration, make it easier to maintain the codebase, reduce the risk of project failure, improve code quality, increase productivity, improve customer satisfaction, and create a culture of continuous improvement.
https://www.gremlin.com/blog/how-to-safely-manage-change-in-a-ci-cd-world/
https://wa.aws.amazon.com/wat.question.OPS_5.en.html
https://martinfowler.com/articles/branching-patterns.html
https://martinfowler.com/articles/continuousIntegration.html