My first encounter with software configuration management was way back in the eighties while at university – and way before I knew that it was called software configuration management. We were doing a student project and were five people working on this group project. I was coding away, slipping into experiments that eventually took the wrong directions – now where was that undo button? We were stepping on each other's toes overwriting changes from others or updating files with unpleasant and surprising side effects. All this hampered our productivity and caused us to have to work late nights to meet our deadline.

The professor, who later was to become my Master's thesis supervisor, told me that it was called software configuration management and that I would get the Nobel Prize in Computer Science if I solved the problem. He was involved in a start-up suffering more or less the same kind of problems. When I graduated I got a job in the industry – but problems persisted. We compiled older versions of modules, forgot to link in a couple of files in the executable or linked versions that had not been re-compiled. Often not causing big disasters, but still a mess that created a general feeling of confusion and uncertainty and caused quite a lot of rework. Apparently there was something they had not taught us at university. So after a while I returned to the university to do research and teaching (and from time to time help out companies)
in software configuration management.

Later on I learned that (software) configuration management to companies (and standards organizations) meant something slightly different. It was more of an administrative and bureaucratic control activity with an emphasis on managing changes, preserving the integrity of the product and providing traceability between artefacts. This is also important for a project. However, it is comparable to putting brakes on the project in order to avoid that it runs out of control, whereas the software configuration management I had known was more like providing a team with a powerful accelerator. If you want to guide a project to a successful result you will need both an accelerator and a brake – and to know when and how to apply each of them (actually some successful Formula-1 drivers apply both at the same time going out of sharp turns). Books that explain about (SCM)brakes and how to use them are plenty and 13 a dozen whereas there is written surprisingly little about (SCM)accelerators – it seems to be practiced by people that are too busy to be able to "preach" it.