Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


In Praise of Small Commits

At my company, tenXer, we gather lots of data about the software development process in the hope of providing managers insight into their projects and the means to deliver the best outcomes.

Due to the significant amount of data at our disposal, we often get asked, "What is one thing that a team can easily do to improve the outcomes of their efforts?" While there is no one-size-fits-all best solution, there is one thing that we often see having an immediate benefit: smaller commits.

Why do smaller commits make an impact? Most people's initial reaction is to focus on the link between smaller commits and faster code reviews. While this is certainly an important benefit, the impact of smaller commits is actually much broader.

Let's start with code review since it's the one benefit most people are familiar with. Smaller commits mean that a fellow engineer has to review fewer lines of code. This means the review is going to be faster from a pure reading aspect, but it also means that there are less lines of code that he needs to decipher and understand. A code review is not just about reading the code, but actually understanding it and making sure the code will do what is intended. Even with the best commenting, the more lines of code that an individual needs to read and understand, the greater the difficulty in translation.

A benefit of quicker reviews is that the developer spends less time waiting for feedback. When the developer is waiting for the code to be reviewed, his focus changes to a different task. The longer his mind frame stays out of the code that is being reviewed, the harder it is for him to return to it to make changes. It is also more difficult for him to respond to questions that the reviewer might have. The longer a code review is open, the greater the task switching, and therefore, the increase in the probability of defects and duration of the task. Small commits help close this gap.

What about teams who do not use code review? Are there benefits for them? Yes. Smaller commits promote better focus and, thus, code cohesion. When a commit is small, the number of things that the commit is likely to be doing is small. This helps reinforce the principles of modularity.

Another advantage of small commits is simpler testing. When a commit is doing only one or two things, the number of test cases that need to be attached to the commit is smaller. It's also easier to debug a small commit because there are a limited number of functions and lines that can be causing an issue.

In a continuous integration environment, the speed at which commits are tested, added to the build, and possibly reverted is paramount. Builds are also faster for small commits because they are, by nature, smaller. Faster and more frequent builds translates into getting the product out faster and getting feedback more quickly. And because the commit is small, if you need to revert back to an earlier version of a build, that is also easier to do. An added benefit is that if you need to remove a commit that has a small scope of functionality, only that piece needs to be removed from the build, which leaves other features intact.

Finally, I should point out that smaller commits help teams achieve more consistent cadences. You can create an analogy between smaller commits and smaller user stories. Why do people break down user stories to their smallest components? It is so that there can be a better understanding of the scope of the task, what is required to get it done, and so that pieces of work can move independently through the development cycle. All of these same principles apply to smaller commits. Smaller commits can move through the development cycle independently. When work is decoupled, the impact of delays or rework from one piece of work on another is minimized. The result of this is reduced variability in cycle time and greater visibility into what has been done and what needs to be done.

Ultimately, managers want to deliver more value in less time — while keeping the team happy. Through smaller commits, engineers get their code reviewed faster, which means less task switching, less waiting, faster testing, and finally, code being pushed to production faster. Code in production faster with less churn = happier developers.

Legendary ex-Facebook Engineer Evan Priestley, the founder of Phabricator, summarized in a blog post many of the benefits of small commits mentioned above: "Small, simple commits are generally better than large, complex commits. They are easier to understand, easier to test, and easier to review. The complexity of understanding, testing, and reviewing a change often increases faster than its size: Ten 200-line changes each doing one thing are often far easier to understand than one 2,000 line change doing ten things. Splitting a change which does many things into smaller changes which each do only one thing can decrease the total complexity associated with accomplishing the same goal."

So, if you are looking for one easy way to start helping your team improve, start tracking and reducing your commit size. No matter what process you follow, whether it's Waterfall, Agile, or Lean, smaller commits will aid your team in delivering work at a higher quality and at a more consistent pace. The notion of smaller commits may seem trivial, but they are an example of a little thing that can make a big difference.

Jeff Ma is the CEO of tenXer, a company that provides managerial intelligence for software development teams. Jeff was the subject of the best-selling book Bringing Down the House and the hit movie 21. He is @jeffma on Twitter.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.