Software Configuration Management Patterns Effective Teamwork, Practical Integration

Effective software configuration management (SCM) strategies promote a healthy, team-oriented culture that produces better software. Software Configuration Management Patterns alleviates software engineers' most common concerns about software configuration management-perceived rigidity and an overemphasis on process. Through the use of patterns, the authors show that a properly managed workflow can avert delays, morale problems, and cost overruns. The patterns approach illustrates how SCM can be easily and successfully applied in small- to mid-size organizations. By learning how these patterns relate to each other, readers can avoid common mistakes that too often result in frustrated developers and reduced productivity. Key coverage includes instruction on how to: Develop the next version of a product while fixing problems with the current one. Develop code in parallel with other developers and join up with the current state of codeline. Identify what versions of code went into a particular component. Analyze where a change happened in the history of a component's development. Use current tools more effectively, and decide when to use a manual process. Incrementally introduce good practices into individual workspaces and throughout the organization. Identify crucial aspects of the software process so that team projects can run smoothly. Build and foster a development environment focused on producing optimal teamwork and quality products. Software Configuration Management Patterns also includes a detailed list of SCM tools and thorough explanations of how they can be used to implement the patterns discussed in the book. These proven techniques will assist readers to improve their processes and motivate their workforce to collaborate in the production of higher quality software. 0201741172B09202002

Stephen P. Berczuk has been developing objectoriented software applications since 1989 Brad Appleton has been a software developer since 1987

Software configuration management is not what I do. I am not a software configuration management person. I am not an organizational anthropology person. However, I discovered early on that understanding organizations, software architecture, and configuration management was essential to doing my job as a software developer. I also find this systems perspective on software engineering interesting. I build software systems, and configuration management is a very important and often neglected part of building software systems. In this book, I hope that I can show you how to avoid some of the problems I have encountered so that you can build systems more effectively with your team. I should probably explain what I mean in distinguishing between software configuration management (SCM) people and people who build software systems. The stereotype is that configuration management people are concerned with tools and control. They are conservative, and they prefer slow, predictable progress. They are also "the few" as compared with "the many" developers in an organization. Software engineers (so the stereotype goes) are reckless. They want to build things fast, and they are confident that they can code their way out of any situation. These are extreme stereotypes, and in my experience, the good software engineers and the good release/quality assurance/configuration management people have a common goal: They are focused on delivering quality systems with the least amount of wasted effort. Good configuration management practice is the not the silver bullet to building systems on time, nor are patterns, Extreme Programming (XP), the Unified Process, or anything else that you might hear about. It is, however, a part of the toolkit that most people ignore because they fear "process," often because of bad experiences in the past (Weigers 2002). This book describes some common software configuration management practices. The book will be particularly interesting to software developers working in small teams who suspect that they are not using software configuration management as effectively as they can. The techniques that we describe are not tool specific. As with any set of patterns or best practices, the ease with which you can apply the patterns may depend on whether your tool explicitly supports them. Why I Wrote This Book I started my software development career with a small R&D group based in the Boston area. Aside from the many interesting technical problems we encountered as part of our jobs, we had the added twist of having joint development projects with a group in our parent company's home base in Rochester, New York. This experience helped me recognize early in my career that software development wasn't just about good design and good coding practices but also about coordination among people in the same group and even teams in different cities. Our group took the lead in setting up the mechanics of how we would share code and other artifacts of the development process. We used the usual things to make working together easier, such as meetings, teleconferences, and e-mail lists. The way we set up our (and the remote team's) software configuration management system to share code played a very large part in making our collaboration easier. The people who set up the SCM process for our Boston group used techniques that seemed to have been tried throughout their careers. As I moved on to other organizations, I was amazed to find how many places were struggling with the same common problemsproblems that I knew had good solutions. This was particularly true because I had been with a number of start-ups that were only one or two years old when I joined. One to two years is often the stage in a start-up where you are hiring enough people that coordination and shared vision are difficult goals to attain. A few years into my career, I discovered patterns. Erich Gamma, Richard Helm, Ral