catch up before checking in

I know it has been said many times before, and I know it’s just common sense, but after a little incident this morning I think it bears repeating: When you’re ready to check in your updates, be sure to catch up with the latest version before starting the check-in process.

We – my pair partner and I – were doing a little refactoring exercise at the end of a programming episode. We decided we had done enough for now, so we’d check in what we had and move onto the next card. So we fired up the SourceSafe (I know, I know) check-in process. It told us that someone else had changed one of our source files since we had checked out. That’s good: it prevented us trampling over someone else’s work. We went through the merge items and satisfied ourselves, by eye, that we had made the right choice in each case. SourceSafe then went ahead and committed the merged version to the integration stream. Wait a minute – that means we just checked in code that had never compiled, let alone passed any tests!

Fortunately, in this case no harm was done. Our merge-by-eye had worked. This time. But any decent CM tool should behave differently, in my opinion. Instead of merging and then checking in with cavalier disregard for the consequences, it should have simply aborted the check-in process when it noticed we were out of date. So now we’re forced to adopt a convention, a team policy that says

“merge from the integration stream into your workspace before every check-in, then re-build and re-test, and only then check in.”

I very much dislike the idea of having to rely on a policy for something like this. I find it very difficult to adopt new habits, and onerous to have a whole list of things to remember each time I carry out a task. And to ask a whole team, or department, to do the same is somewhat optimistic, to say the least. We need a CM tool that “stops the line” and forces us to catch up before we are allowed to proceed. This would follow the Toyota principle of jidoka or autonomation, effectively eliminating one source of manual error and rework.

(More on catching up before checking in can be found in the literature on team streams.)

Update, 21 jun 05
Subversion gets it right, of course.

Advertisements

everything in its place

A couple of weeks ago I finished reading Gemba Kaizen by Masaaki Imai. Just like all the other books on lean manufacturing, I found it extremely rewarding and thought-provoking, while at the same time being somewhat longer and more repetitive than I might have wished (the second half comprises an interminable list of case studies, many of which add very little to the value of the book).

The main idea I took away from the book was that of 5S. This is basically rigorous and institutionalised house-keeping (translated as Sort, Straighten, Scrub, Systematize, Standardize). The idea is that an untidy or disorganised workplace can contribute significantly to reducing the throughput of value for the customer.

Can this concept be applied to software development? I believe so. All our tools have to be readily accessible when needed. Our codebase, workspace and CM system should all be well-organised, and should contain nothing that isn’t needed to add value or promote flow. Our build should be clean and automated, and driven only from components that are CM-controlled. And when we’re working as a team, all our processes and techniques should be standardized so that each person’s actions are understandable by all.
Continue reading