The subtle discipline of daily commits and value delivery

What if I told you that it is really good for a software developer to do daily commits to Git/Mercurial? Many would claim it’s not essential and they prefer to take a few days to “properly” craft a commit.

Programming is an art, and it requires careful coding and merging, right? Why rush and commit frequently?

Wiser developers know that daily commits are extremely important.

The truth is some of the best contributors on Github have daily commits or a high commit frequency. E.g. TJ Holowaychuk (creator of Node.js Express) has a very nice commit frequency:

However, shiny graphs and statistics are not the purpose of this discipline and there are best practices to learn to become a daily committer.

Introducing daily commits can be painful

When we introduced daily commits at Ministry of Programming We explained it as a continuous integration best practice.

Unexpectedly, this rule was misunderstood by some of our team members.

Developers started committing just to have a daily commit and some of them started making X commits per day that didn’t really make sense just to make it look good in statistics and to honour the rule we have established.

What is the problem with these commits? they certainly add some value to the codebase, but the devil is in the details.

The real value of daily commits and daily PR’s

Daily commits are a continuous integration discipline promoted by Jez Humble, one of the most well-known DevOps influencers.

It is actually one of the questions that Jez asks to verify if a team is doing Continuous Integration:

“Are all the engineers pushing their code into trunk / master (not feature branches) on a daily basis?” — Jez Humble

Why are daily commits so valuable? For the following reasons:

• Small PR’s (and commits) are easier to code-review instead of large PR’s
• Small commits contribute to team-work and build trust in the team since the contributions are visible and frequent
• A well-crafted commit is releasable (it enables daily builds)
• A daily commit (and build) delivers business and user value to production users, which is the ultimate purpose of most software development projects
• A daily commit contributes to continuous integration, which can reduce risk of unsuccessful merging and delayed integration of software components
• A daily commit builds a discipline of continuous delivery since it’s a habit of providing value
• Daily commits can be aligned with tasks, subtasks and acceptance criteria, which makes them even more valuable to the team
• Daily builds are one of the few metrics that enable comparison of efficiency between software teams. They are a way to benchmark your team against other teams.

The state of DevOps report identifies high performing teams by their Deployment frequency. How can you have a high deployment frequency without daily commits?

Without a daily commit there is no daily build.

Frequent deployments enable daily builds and reduce time to market for a product, which increases the chance of success. I believe that everyone wants to work on successful products, and frequent releases are a product management best practice.

The worst thing for a developer and a product team is to develop something that nobody uses or that will fail. It is important to discover as soon as possible if that is the case. Great software teams have multiple releases per day to production.

A well-crafted commit

A well-crafted commit is pure user or business value packaged as a chunk of code.

A good commit has the following characteristics:

• A connection to a specific Task that quantifies the user/business value
• A good, understandable description (and related documentation)
• Automated tests that make it immediately releasable to production users

An example of this from our code-base:

This commit is very small, it has a clear link to a feature that delivers business/user value, it has a clear description of what is delivered (also included in the related PR) and it is releasable to production users.

Also, committing frequently this way reduces a chance that a large commit will cause a merge issue.

This is pure value delivery by a developer, and it increases the chance of success of a product/project.

Having a daily commit like this builds trust among the team and promotes high productivity since everyone wants to deliver more and more to production users and celebrate success or learn from failure.

Finally, well-crafted daily commits are the ultimate measure of productivity and discipline. It feels great to deliver daily.

Daily Commits require careful planning by developers

To craft a good daily commit and maintain the frequency you need an “Execution Plan” for your daily development.

A good practice is to make some coffee and put together a checklist at the start of your day so you know what to deliver in a commit.

Don’t waste the opportunity to plan your day and rush into your IDE to code, since it will be much harder to understand how to craft a good daily commit if You don’t design carefully what components/modules you plan to add or modify and how to make your code releasable to production users.

Without upfront planning you might end up Yak-Shaving and working across different components and even across tasks. This will diminish your chance to package and deliver a daily commit since you are not focused on delivery but on coding.

Never postpone continuous integration for your own comfort. Think about your team and your product.

Coding does not deliver value, releasing does.

You can find more advice about crafting good daily commits in the continuous delivery book by Jez Humble.

Conclusion

I believe that Daily Commits are an essential discipline to reduce risk and provide value to end-users of a product/project. It is pure continuous integration and delivery in action.

However, the devil is in the details and a daily commit that is not crafted properly is not real value, but noise and overhead.

And finally, a daily commit should not be a choreography, but an act of value delivery.

You should not commit anything, but something that delivers user or business value or something that reduces future integration risk.

When in doubt, it is better not to commit, but anyway ask Yourself “When and how am i going to deliver real value?”

I would like to hear about your own experiences with Daily commits and PR’s and the effects of this rule in your team.