Going back a couple of years, the development group I was contracting in at the time had decided to move out of its present chaotic state and start using a development process. I wonder how well that sentence conveys what they were planning to do? Just to clarify, the plan was this: all permanent development staff would go home one leaving the chaos behind, and when they came back the following morning they would be following whatever process/methodology they adopted.

Oh well. I’ve heard of this sort of madness before, but that’s one of only two instances I’ve come across it in my personal experience. I’m sorry to say it, but I was actually involved in the other one! Don’t tell any one – it was years ago and I’ve learned a lot since then. In passing, note that I’m interested in hearing such experiences – or indeed any related experiences – from other people.

Anyway, when the contract client I alluded to above went methodological my contract was coming to a close anyway. Consequently I wasn’t around long enough to see how it turned out for them. Note that above I refer to their approach as madness. This is because I think the problem of this kind of taming of a development environment is too big to solve in one go – even if the development group is quite small, say only five people. My own experience was that when a blanket process is introduced it doesn’t last very long. People either just go back to the way they used to do things, or they just never really start using the process. Either way, the process fails.

How then, should a development group move from chaos to discipline? The answer is simple: solve on problem at a time! Look around and identify something that is not working well, and work out how to change it for the better. For example, a few years ago I was working on a project for which the code was all written in C++. We had a couple of programmers who, although strong on some of the project technology (such as obtaining telemetry from various hardware) were relatively inexperienced in C++ programming techniques. We addressed this problem by introducing pair programming, to be used as and when needed. The technical lead was adept at keeping closely in touch with team members anyway, and simply organised the pairings as and when necessary. Note that although my C++ is/was very strong, I had been working on the project for a much shorter time than these two programmers. Therefore I was almost always paired as the “C++ mentor”, because then I could learn other aspects of the project from the programmer I was working with – thus making the pairing an exchange from which both of us, and hence the project, benefited.