Again and again I see example of why it pays off to have small commits. By that I mean something very practical, namely a commit to a version control system.
As I work through a story I don’t implement the entire story in one go. Instead I look for even smaller steps, ideally using tests to drive the development.
When I say small I mean more on the scale of every few minutes rather than maybe a couple times per day.
If something doesn’t work correctly I have only a very small number of places where to look for what is wrong. Most issues I find by just looking at the code changes. This works even better when I work with a programming partner.
As I find most issues by just looking at source code only rarely I need a debugger let alone stepping through vast amounts of code. This, too, is a time saver.
And in case I stuffed up the code completely I don’t lose much work, maybe just a few minutes, and I pull out all my code changes. Then I start from where I was just at the last commit. I continue from a known position.
The principle at work is small increments. This also applies to roadmaps, budget spreadsheets and other items. Just give it a try!
My recommendation: With commits you can’t err on the too small side!
1 comment:
Along those lines, some of the newer source control systems include a "bisect" function - basically performing an automated binary search between known-good and known-bad versions to try to identify the commit that introduced a bug.
Such tools are much more useful if individual commits are small.
Post a Comment