Daniel Irvine on building software
Check in early and often
30 May 2012
On our dev team we’ve decided to add a new build step to our continuous build server that will fail any build unless certain metadata files have been updated as part of a checkin. For the purposes of this post the metadata itself is important, but what is important is that updating the metadata is (currently) a manual task.
And so this objection was raised: this will slow me down considerably - every time I check in I’ll be spending extra time updating metadata!
An absolutely valid point, but I was shocked by the response from one of our developers:
Just don’t check in so much.
When I heard this, my mind stalled. Was he being serious? Yes, I think so; Was he aware of the repercussions of that? Not so sure. Did the rest of the team think what he said was credible? It looks like they did; Do I seriously have to teach them check in early and often, one of the golden rules of software development? I guess so! But... why exactly do we check in early and often?
Sometimes practices are so engrained in us that we forget why exactly we follow them. As developers we should be aiming for the briefest time between check-ins. There are already some great posts on this subject that you should really read and understand. I’d like to just focus on one point: how this fits in with an agile methodology.
A big idea in agile is that of developing complete features. Any feature developed is useful by itself, not just as a part of a bigger featureset. The reason this is important is because agile iterations are so short, for example just 2 weeks. If you have a large feature that will span multiple iterations there’s a danger that at the end of the first iteration you might not have a useful feature to deliver - for example, you might have completed the data model but not the UI views. So rather than split the feature up that way, you should split it up in a cross-functional way that means you’ll end up with a useful feature even if it’s very limited in scope.
There’s the old analogy of slicing a cake: if you want to divide a cake into portions, you don’t do it layer-by-layer, you slice it across all layers, taking a small portion of each layer. It tastes better that way, right? So with software development the idea is the same.
If you’re using test-driven development, then you’re doing this at an even more granular level. You’re writing specifications that directly relate to your user stories. You build up classes method by method using tiny specifications. Using specification style tests means you will always have working software. And so you should be able to check in as often as after every single test.
Moreover, your continuous integration environment should support you in that goal so that your changes are known to exist (can be reviewed, tested, and used by others).
A danger of this approach is that the API you’re writing is likely to change as you evolve your design and add more cross-sectional functionality. So the team should be aware of which sections of code are current works in progress and therefore shouldn’t be relied on just yet.
In summary, agile methodology encourages emergent design via test-driven development and refactoring, and those practices make it easy to check in early and often. And since checking in early and often has so many benefits, you should be insisting that your team follows the “check in early and often” principle.