Brad has been writing on the theme of Trust and how to build it which I have found interesting.
Something I have been concerned with for quite some time now is the concept of “Selling CM” (Configuration Management) – how to communicate the value of it to other people. As an aside, I am looking forward to a couple of the presentations at the upcoming BCS CMSG Conference on this theme (Richard Morreale and David Cuthbertson). There are of course some external issues which are raising the profile of CM – in particular Corporate Governance (Sarbanes Oxley in the US and The new Companies Bill in the UK). These help to give it a higher profile, but if we’re not careful will lead to being accused of “crying wolf”.
As someone working in the field and convinced by the value and benefits of CM, it was fairly easy when working on development projects just to get on and do it. I tended to find that developers with some experience had been bitten by problems that resulted from bad CM practices, and were reasonably happy with a sensible system that helped avoid it (because they didn’t want to implement and I did, they were happy to let me at it!).
As I am now working as an external consultant, I tend to be at one remove in that I am providing consultancy and training and much more frequently come across people who don’t understand the need for it. Since I can’t do it for them, I have to persuade and educate them in such a way that they become interested enough to do it themselves (of course I come across a wide range of people on training courses, from the keen enthusiastic ones to the “I’m here because my boss sent me and I’m not interested” types).
I’ve been developing as a trainer in terms of how to best communicate things and put people in situations that they discover things for themselves, and this is very much an ongoing field of study for me.
However, back to the original topic of communication…
I realised recently that we can look at CM as a means of communicating information to other people. Writing the code itself is a means of communication – one of the experiences highlighted by agile is how much documentation gets generated in software development that turns out to be useless. Valuing working systems over documentation is because a working system communicates more accurately than documentation which tends to be out of date.
CM repositories are where people store their code. But how people use those repositories makes a huge difference to their usefulness. If you think about what you are trying to communicate when you use the repository you can increase the amount of information communicated with little or no extra effort – just some thought.
For example, let’s look at the pattern of Task Level Commit which talks about grouping files together as change sets. Rephrasing it a bit, the grouping of changes to individual files into one change set is a very useful piece of information which has value to other people. If I am using a tool which doesn’t support change sets, then I may try and communicate this extra information by checking in the individual files at a around the same time with the same comment (or reference to some external defect). The problem is how easy that information is to extract – often difficult if the tool doesn’t support it.
Another way of losing information is by checking in a large change set with say the fixes to 5 defects all mixed together. This makes it difficult to extract the information about individual bug fixes. In some instances this is not a major problem (if say the bugs all needed to be fixed anyway and are all going in to the same release). However, if you are using branches and wish to propagate changes between branches, and not necessarily all of the changes, then you have to split the all singing all dancing change set up and extract the relevant bits. This is usually more work if you are lacking the information about which changes fixed which bug because the changes are recorded as a change set.
I have also heard people ask about making a fix to 2 branches – instead of making the fix once and propagating it, they think it is easier just to make the same code change in the 2 places with only a comment to link them. Again, this is losing information which can be useful in the future. (Note that sometimes it is worth fixing a bug in 2 branches in 2 different ways – for example a work around quick fix in a release branch, and a considered proper fix in the mainline – in such circumstances you need to think about how to convey the information).
The precise details of how you convey the information will depend on your tool. The key step when making any change is to think “what information about this is important for the future and how can I best use the tool to record that information for posterity?”.
One way I have heard of this being described is to “use the tool to record your intention” rather than just make a change.
