Know Your Next Commit
Know Your Next Commit
I tapped a programmer on her shoulder and asked what she was doing. “I am refactoring these methods”, she answered. I tapped a second programmer on his shoulder and asked what he was doing, “I am adding some parameters to this web action”, he answered. The third answered. “I am working on this user story”
It might seem that number one and two where focusing on details of their work and that the second focused on the bigger picture, and that the latter should be better. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and where to be finished within an hour or so. The third programmer answered: “Oh, I guess I will be ready within a few days; I will probably add a few classes and might have to change those services some way.”
The first two programmers did not lack consideration of the over-all goal of what they where doing. But, they had selected a task that they could get a grip on, that led in a productive direction, and they thought could be finished within two hours. Once they had finished that task, they would select a new change or refactoring. In that way all the code they wrote where written with a clear purpose and a limited and achievable goal in mind.
The third programmer had simply not been able to break down the problem and where working on all of it at one go. He had no idea of what it would take, and where basically doing speculative programming, hoping that he would arrive at some point where he would be able to commit. Most probably the code written in the start of this long session where poorly directed for the solution that came out in the end.
What would the two programmers do if the task they had selected came out to take more than two hours? They would simply realise that they had taken too big a bite, throw away their changes, define a smaller task, and start over. To keep working would have been speculative, and you do not want speculative code in your repository. So, the changes where thrown away, but the insights where kept.
On the other hand, the third programmer would probably just keep guessing with less and less clue and desperately try to patch together his changes to something that could be committed. Because, you cannot throw away code-changes you have done – that would be a waste of work wouldn’t it? Unfortunately that causes a lot of strange code-changes without a clear purpose to enter the repository.
At some point of time even the commit-hard-ass programmers could not find something they thought could be finished in two hours and would lead in a productive direction. Then, they would go directly into speculative mode and play around with the code: trying some wild refactoring just to see how the code would move, or patching on some functionality to see if it would fit in the structure – and of course throwing away the changes whenever they had gained some insight leading them on track. Because, of course even these seemingly unstructured hacking sessions had a purpose: to learn about the code to be able to define a task that would constitute a productive step.
Know your next commit. If you cannot finish, throw away your changes, and define a new task you believe in with the insights you have gained. Do speculative experiment whenever needed, but do not let yourself slip into speculative mode without noticing. And never let speculative code enter your repository.