Size Matters
In software development, every change we make introduces a risk, from additional feature work to config changes and library upgrades. We employ a variety of practices aimed at reducing risk, not least of all conducting comprehensive testing for each change that goes through our development pipeline, and we are always on the lookout for additional practices that can further reduce our exposure. However sometimes practices that seek to reduce risk can, in fact, have the opposite effect.
Every team makes decisions, either explicit or implicit, about the size of the changesets they will accept. Should a change be merged? If so, when? At what point should a change be submitted for testing phases? And when should a change be deployed to a production environment? When trying to mitigate risk, it can often be tempting to prefer to batch changes up — perhaps only accepting features into the trunk once they are complete, or adopting a relatively slow release cadence, releasing many changes to production every few months. This can seem like a good idea initially, as it allows more time for QA, and means less potentially risky releases happening. However, keeping things small, focussed and frequent can often be the less risky choice.
Ultimately, whilst at many points the temptation can be to tend towards thinking big, arguably thinking as small as possible can reduce risk.
Small commits
As the smallest unit of change in a project’s codebase, keeping our commits small can help in many ways. By committing small and often you make it much easier to return to an earlier state if needed. This can be helpful when chasing down the cause of an issue during development. They also help us think more iteratively and aid in mentally breaking down a task into achievable chunks. It can nudge us towards more descriptive commit messages instead of generic ones like ‘fix’. Additionally they serve as a backup of your work in progress — this means should you unexpectedly be called away, another member of the team can pick up your work more easily, with the commits serving as an annotated history of what has been done so far. This, of course, relies on the commit messages being descriptive so it is easy to follow the work that has been done so far. If there are concerns about the trunk being ‘messy’ as a result of lots of tiny commits, they can be squashed when a PR is merged, and most modern VCS platforms, for example Github, will preserve the original commits if needed.
Small PRs
If, like many teams, you organise review and testing activities around Pull Requests, it can be tempting to enforce that a PR encapsulates a finished feature or piece of work, or to batch them up into larger ones to ensure that reviewers or test personnel have ‘only one’ to deal with. However keeping the size of your pull requests small has many advantages. For team members conducting code reviews, smaller ones with less changes are much easier to review.
https://twitter.com/iamdevloper/status/397664295875805184
For testers this is true as well — smaller changesets mean the changes made are much easier to understand whilst looking for issues. This can then feed back into more focussed bug reports. Depending on your testing processes, smaller PRs can mean that testers have a narrower scope to explore, and can mean as a result that testing is more exhaustive as opposed to attempting to cover a wider area less profoundly. However these benefits require investment into additional mechanisms which support and enable this behaviour — for example feature toggles, and mature and reliable automated testing. Many teams may already have some of this in place, however if not the development and test overhead involved in implementing these should be considered as part of the discussion.
This principle is equally applicable for teams working in feature branches — minimising the size of PRs that get merged into these branches can help the team with code reviews, QA reviews, and bug analysis, even if the work is not being pushed to the main branch or to production initially.
Small and frequent deployments
Releasing to production environments is often seen as an inherently risky event. This can often lead teams to batch up many changesets to be deployed all at once — a ‘big bang’ release.
Counterintuitively though, this behaviour exacerbates risk. Pushing multiple changes into production can make for a much more complex release process, requiring a significant level of coordination across many team members, and if something goes wrong it can be difficult to diagnose which of the many changes has caused the issue. If we aim to deploy more regularly, the team will become more confident in the process of deploying and are more likely to ensure that processes and tooling exist enabling post-deployment monitoring and easy rollbacks.
https://twitter.com/AutomatedTester/status/943401558871629825
Small changesets can help us by encouraging this behaviour. These reduce the footprint of our deployment, and therefore reduce risk. If something goes wrong, the scope of the change is smaller which makes finding the issue much quicker and easier. The reduced risk can encourage us to deploy more frequently. This, in turn, can help us move towards a continuous deployment model. However, as we progress in this direction, it is important to have the necessary tooling in place — in order to be able to release frequently with confidence, a reliable set of build pipelines are needed, with automated quality checkpoints and established rollback procedures.
Small is beautiful
As ever, this is not to say that there is a universal optimum size for each commit, PR or release — this will differ between teams and projects and will depend heavily on the context. Furthermore, making some of these changes can take a lot of effort at first. However, in many cases, tending towards smaller changesets can reduce risk and improve both quality and velocity. As with many changes it is unlikely to happen all in one event. Instead it can be a good first step to look at current processes, and see if making one small change — for example increasing release cadence slightly, or trying to keep PRs small — can help move the team in the right direction. Whilst it can be tempting to tend towards large units of work and this can initially seem to be the safest option, it can pay dividends in both quality and speed to ‘think small’.
Head over to Lydtech Consulting to read this article and many more on testing and other interesting areas of software development.
