Monthly Archives: September 2013

Autobiography

Poetry and Art

I am the boy sitting by the water.
With his pocket knife against a walnut,
and the walnut against his thumb.

With a deliberate squeeze,
he split it into two halves,
and beheld the hull of a ship.

It was a grand vessel,
you should grant him that,
and he didn’t feel cramped at all,
until you pointed it out.

You would have him build a rudder,
but I am glad he left without a mast.
For what is this pretense
that we control our direction.

Donato Borrello

Resisting the Big Submit

Programming

I’ve seen it too many times – a submission into Version Control with a description which is the laundry list of fixes and changes that happened to be bundled together. When changes lose their focus and do more than one thing, it is incurring an organizational debt that will be paid later. Whether it comes in the form of having to roll-back, do a complex merge, or even by camouflaging a change when someone looks through a files history.

It wouldn’t be fair to ask if you have ever submitted a change which fixed more than one issue. Sure you have, we all have, we love fixing things, but suppose you fixed one bug and you also wanted to tidy up some white-spacing issues at the same time. This natural tendency to neaten things up as we go is awesome and probably the sign of a conscientious team member, but it isn’t quite right. It is a micro-example of the same issue.  It will still make diffs harder to read, and has the potential to slow down merges depending on which software you are using. Life is easier when we have thousands of simple diffs where each has only a single purpose.

In practice this isn’t so easy.

  • It is inconvenient to keep opening a file for edit, making a small change, submitting and writing a description
  • We face bugs which have side-effects, which raises the question: does it make sense to fix the bug and its side-effects separately?
  • Some people are wary of bloating the change-history for a specific file (although they shouldn’t be)

It all comes down to workflow. If you want to convince an entire team to work with a similar style, it has to make their life easier. If it takes a minute to submit a white-space change then there is 60 seconds a developer is wasting his time, when he could have just lumped it into something else for free.

So why not let him lump the solution together, and then submit them separately? This is possible with Git (by using the “s” option you can separate out the changes within a file into multiple chunks). However this is impossible with CVS, SVN and Perforce which each operate on a per-file basis.

This denotes the importance of choosing a proper source control. The system sets the tone for every interaction between the engineers and their codebase. If you want to encourage good habits and make your developers happy, then you need to make it easier than the alternative bad practice.