Lars Bendix:
Foreword,
in Marc Girod, Tatiana Shpichko IBM Rational ClearCase 7.0: Master the Tools That Monitor, Analyze, and Manage Software Configurations, Packt Publishing, April, 2011.

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.

This is why this book is so valuable to practitioners as it deals with accelerators. How you avoid all those small mistakes that create a big mess and make your working life miserable. Software development is by nature most often the collaborative effort of a team of people. This team may be located locally or it may (as it happens more and more frequently because experts are hard to come by locally) be a distributed team. No matter what, people should be allowed to be productive and to work together as efficiently as possible. Build management with fast and reproducible builds is important for traditional development, but becomes even more important if you want to go with agile development methods. Imagine what would happen to the Test-Driven Development cycle of "write unit test(s), build the system, run the system, write code" if the "build the system" phase would take two hours to complete. Agile methods thrive on quick, immediate feedback (one of Kent Beck's fundamental values for Extreme Programming) and therefore demand fast (and reliable) builds.

During my years as a teacher, I have time and again met students who brought the latest version of a document or some code with them to our supervising meetings instead of the version they had sent me one or two days earlier. Every year I experience the thrill of seeing students on our second year project course step on each other's toes and pull the rug from under each other – at least in the beginning of the project period. From what I have seen during years of interaction with industry the situation in many companies is not that much better. Apparently good software configuration management behaviour is not baked into our DNA – and sadly neglected in the teaching of software engineering at most universities.

This is why this book is so valuable to everyone involved in software development. Most often if we follow our individual instincts we tend to ignore the communication and co-ordination that has to take place in a team effort and confusion and misunderstanding will be the consequence. Key concepts like integrity, reproducibility and traceability – good, old-fashioned configuration management concepts – are fundamental building bricks in any solution to that situation. So easy to pronounce, yet so difficult to implement and practise – Marc and Tanya take you by the hand and show you how.

I did not get my Nobel Prize, nor will this book earn Marc and Tanya the Nobel Prize in Computer Science. Not because the book isn't good – it is excellent – but because it is too practical and hands-on. Marc and Tanya are a strong team with many years of practical experience from both software configuration management and ClearCase usage. They are both driven by a strong passion for doing things the right way – and a deep curiosity for how to use a tool for most benefit and for exploring and pushing the boundaries of a tool's capabilities. ClearCase is a wonderfully powerful tool – but also somewhat difficult to master in particular for its more advanced features. I have seen students at computer labs shoot off both their feet in two seconds flat – and still walk away at the end of the lab thinking "what an awesome tool with all this cool stuff that it can do" – and they only scratch the surface in their labs.

This is why this book is so valuable because it brings together two capacities – one explaining the use of the other. If you go for a tool like ClearCase it should be because you want and need something more than "the ordinary SCM tool" can offer you. Marc and Tanya explain you how to take full advantage of ClearCase (and some of its more advanced capabilities) through a series of hands-on examples.

If you do not use ClearCase you may still want to read this book. Just skip the specific details and code examples related to ClearCase and enjoy the general guidelines and principles about software configuration management that Marc and Tanya introduce and explain. At the end of the book you'd probably wish you did use ClearCase.

Lars Bendix, Ph. D., ETP
Lund University, Sweden March, 2011