BN.com Gift Guide

Software Configuration Management Patterns: Effective Teamwork, Practical Integration

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (17) from $1.99   
  • New (6) from $45.99   
  • Used (11) from $1.99   

Overview

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

Read More Show Less

Product Details

  • ISBN-13: 9780201741179
  • Publisher: Addison-Wesley
  • Publication date: 11/28/2002
  • Series: Software Patterns Series
  • Edition description: New Edition
  • Pages: 218
  • Product dimensions: 7.37 (w) x 9.18 (h) x 0.54 (d)

Meet the Author

Stephen P. Berczuk has been developing object-oriented software applications since 1989, often as part of geographically distributed teams. He has been an active member of the Software Patterns community since the first PLoP conference in 1994, and did early work on the relationship between organization, software architecture, and design patterns. He has an M.S. in Operations Research from Stanford University and an S.B. in Electrical Engineering from MIT.

Brad Appleton has been a software developer since 1987 and has extensive experience using, developing, and supporting SCM environments for teams of all shapes and sizes. A former Patterns++ section editor for the C++ Report, Brad is also well versed in object-oriented design and agile software development, and cofounded the Chicago Patterns and Chicago Agile Development Groups. He holds an M.S. in Software Engineering and a B.S. in Computer Science and Mathematics.

0201741172AB09202002

Read More Show Less

Read an Excerpt

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 problems—problems 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, Ralph Johnson, and John Vlissides were just finishing the book Design Patterns (Gamma et al. 1995), and the Hillside Group was organizing the first Pattern Languages of Programs (PLoP) conference. There is a lot of power in the idea of patterns because they are about using the right solution at the right time and because patterns are interdisciplinary; they are not just about domain- or language-specific coding techniques but about how to build software from all perspectives, from the code to the team. I presented a number of papers in workshops at the various PLoP conferences that dealt with patterns at the intersection of design, coding, and configuration management (Berczuk 1995, 1996a, 1996b; Appleton et al. 1998; Cabrera et al. 1999; Berczuk and Appleton 2000).

At one PLoP conference, I met Brad Appleton, who is more an SCM expert than I am. We coauthored a paper about branching patterns (Appleton et al. 1998), just one aspect of SCM. After much encouragement from our peers, we started working on this book.

I hope that this book helps you avoid some common mistakes, either by making you aware of these approaches or by providing you with documentation you can use to explain methods that you already know about to others in your organization.

Who Should Read This Book

I hope that anyone who builds software and uses a configuration management system can learn from this book. The details of the configuration management problem change depending on the types of systems that you are building, the size of the teams, and the environment that you work in. Because it's probably impossible to write a book that will address everyone's needs and keep everyone's interest, I had to limit what I was talking about. This book will be most valuable to someone who is building software, or managing a software project, in a small to medium-size organization where there is not a lot of defined process. If you are in a small company, a start-up, or a small project team in a larger organization, you will benefit most from the lessons in this book. Even if your organization has a very well-defined, heavy process that seems to be impeding progress, you'll be able to use the patterns in this book to focus better on some of the key tasks of SCM.

How To Read This Book

The introduction explains some basic concepts of software configuration management and the notation that the diagrams use. Part I provides background information about SCM and patterns. Chapter 1 introduces the software configuration management concepts used in this book. Chapter 2 talks about some of the forces that influence the decisions you make about what sort of SCM environment you have. Chapter 3 introduces the concept of patterns and the patterns in this book and how they relate to each other. Part II consists of patterns that illustrate problems and solutions to common SCM problems. Chapters 1 and 2 also define the general problems that this book addresses. To understand the how patterns fit together, you should read Chapter 3 to get an overview of the language.

After you have read the first three chapters, you can browse the patterns in Part II, starting with one you find interesting and following with ones that relate to your problem. Another approach is to read the patterns in order and form a mental picture of the connections between them.

The references to the other patterns in the book appear in the introductory paragraph for each chapter and in the Unresolved Issues section at the end of each chapter, using a presentation like this: Active Development Line (5). The number in parentheses is the chapter number that contains the pattern.

Because this is a large field to cover, some of the context and Unresolved Issues sections don't refer to other patterns, either in the book or elsewhere, because they haven't been documented as of this writing. In this case, you will see a description about what a pattern might cover.

Origins of This Material

Much of the material in this book has its origins in papers written for various Pattern Languages of Programs conferences by me, Brad Appleton, Ralph Cabrera, and Robert Orenstein. The patterns have been greatly revised from the original material, but it's appropriate to mention these papers to acknowledge the roles of others in this work: "Streamed Lines: Branching Patterns for Parallel Software Development" (Appleton et al. 1998), "Software Reconstruction: Patterns for Reproducing the Build" (Cabrera et al. 1999), "Configuration Management Patterns" (Berczuk 1996b).

Steve Berczuk
Arlington, Massachusetts, June 2002
steve@berczuk.com http://www.berczuk.com

Why I CoWrote This Book with Steve

I began my software development career in 1987 as a part-time software tools developer to pay for my last year of college. Somehow it "stuck" because I've been doing some form of tool development ever since (particularly SCM tools), even when it wasn't my primary job. I even worked (briefly) for a commercial SCM tool vendor, and part of my job was to stay current on the competition. So I amassed as much knowledge as I could about other SCM tools on the market. Even after I changed jobs, I continued my SCM pursuits and frequented various tool user groups on the Internet.

At one time, I longed to advance the state of the art in SCM environments and kept up with all the latest research. I soon became frustrated with the vast gap between the "state of the art" and the "state of the practice." I concluded that I could do more good by helping advance the state of the practice to use available tools better. Not long after that, I discovered software patterns and the patterns community. It was clear that these folks were onto something important in their combination of analysis and storytelling for disseminating recurring best practices of software design.

At the time, hardly anyone in the design patterns community was attempting to write SCM patterns. SCM is, after all, the "plumbing of software development" to a lot of programmers: Everyone acknowledges that they need it, but no one wants to have to dive into it too deeply and get their hands entrenched in it. They just want it to work and not to have to bother with it all that much.

It didn't take long for me to hook up with Steve Berczuk. We wrote several SCM patterns papers together (with Ralph Cabrera) as part of my ACME project at http://acme.bradapp.net/ and later decided to work on this book. We hope this small but cohesive set of core patterns about integration and teamwork helps the unsuspecting developers-cum-project-lead survive and thrive in successfully leading and coordinating their team's collaborative efforts and integrating the results into working software.

Brad Appleton
Arlington Heights, Illinois, June 2002
brad@bradapp.net http://www.bradapp.net

Read More Show Less

Table of Contents

List of Figures.

Foreword.

Preface.

Contributor's Preface.

Acknowledgments.

Introduction.

I. BACKGROUND.

1. Putting a System Together.

Balancing Stability and Progress.

The Role of SCM in Agile Software Development.

SCM in Context.

SCM as a Team Support Discipline.

What Software Configuration Management Is.

The Role of Tools.

The Larger Whole.

This Book's Approach.

Unresolved Issues.

Further Reading.

2. The Software Environment.

General Principles.

What Software Is About.

The Development Workspace.

Architecture.

The Organization.

The Big Picture.

Further Reading.

3. Patterns.

About Patterns and Pattern Languages.

Patterns in Software.

Configuration Management Patterns.

Structure of Patterns in This Book.

The Pattern Language.

Overview of the Language.

Unresolved Issues.

Further Reading.

II THE PATTERNS.

4. Mainline.

Simplify Your Branching Model.

Unresolved Issues.

Further Reading.

5. Active Development Line.

Define Your Goals.

Unresolved Issues.

Further Reading.

6. Private Workspace.

Isolate Your Work to Control Change.

Unresolved Issues.

Further Reading.

7. Repository.

One Stop Shopping.

Unresolved Issues.

Further Reading.

8. Private System Build.

Think Globally by Building Locally.

Unresolved Issues.

Further Reading.

9. Integration Build.

Do a Centralized Build.

Unresolved Issues.

Further Reading.

10. Third Party Codeline.

Use the Tools You Already Have.

Unresolved Issues.

Further Reading.

11. Task Level Commit.

Do One Commit per Small-Grained Task.

Unresolved Issues.

12. Codeline Policy.

Define the Rules of the Road.

Unresolved Issues.

Further Reading.

13. Smoke Test.

Verify Basic Functionality.

Unresolved Issues.

Further Reading.

14. Unit Test.

Test the Contract.

Unresolved Issues.

Further Reading.

15. Regression Test.

Test for Changes.

Further Reading.

16. Private Versions.

A Private History.

17. Release Line.

Branch before Releasing.

Further Reading.

18. Release-Prep Code Line.

Branch Instead of Freeze.

Unresolved Issues.

19. Task Branch.

Handling Long-Lived Tasks.

Use Branches for Isolation.

20. Referenced Patterns.

Named Stable Bases.

Daily Build and Smoke Test.

Appendix A: SCM Resources Online.

The Configuration Management Yellow Pages.

CM Crossroads—Online Community and Resource Center for CM Professionals.

CM Today—Daily Configuration Management News.

UCM Central—Unified Configuration Management.

ACME-—Assembling Configuration Management Environments (for Software).

The Software Engineering Institute's SCM Publications.

Steve Easterbrook's Configuration Management Resource Guide.

The Software Configuration Management FAQ.

The Association for Configuration and Data Management.

Software Engineering Resource List for Software Configuration Management.

R.S. Pressman and Associates Software Engineering Resources for SCM.

SEweb Software Configuration Management Resources at Flinders University.

Pascal Molli's “CM Bubbles” SCM Resources Page.

The Usenet Newsgroup comp.software.config-mgmt.

Appendix B. Tool Support for SCM Patterns.

VSS—Visual Source Safe.

CVS—The Concurrent Versions System.

Perforce.

BitKeeper.

AccuRev.

ClearCase—base functionality (non-UCM).

ClearCase—Unified Change Management (UCM).

CM Synergy.

StarTeam.

PVCS Dimensions.

PVCS Version Manager.

MKS Integrity (Enterprise edition).

Further Reading.

Photo Credits.

About the Photos.

Bibliography.

Index. 0201741172T10072002

Read More Show Less

Preface

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 problems—problems 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, Ralph Johnson, and John Vlissides were just finishing the book Design Patterns (Gamma et al. 1995), and the Hillside Group was organizing the first Pattern Languages of Programs (PLoP) conference. There is a lot of power in the idea of patterns because they are about using the right solution at the right time and because patterns are interdisciplinary; they are not just about domain- or language-specific coding techniques but about how to build software from all perspectives, from the code to the team. I presented a number of papers in workshops at the various PLoP conferences that dealt with patterns at the intersection of design, coding, and configuration management (Berczuk 1995, 1996a, 1996b; Appleton et al. 1998; Cabrera et al. 1999; Berczuk and Appleton 2000).

At one PLoP conference, I met Brad Appleton, who is more an SCM expert than I am. We coauthored a paper about branching patterns (Appleton et al. 1998), just one aspect of SCM. After much encouragement from our peers, we started working on this book.

I hope that this book helps you avoid some common mistakes, either by making you aware of these approaches or by providing you with documentation you can use to explain methods that you already know about to others in your organization.

Who Should Read This Book

I hope that anyone who builds software and uses a configuration management system can learn from this book. The details of the configuration management problem change depending on the types of systems that you are building, the size of the teams, and the environment that you work in. Because it's probably impossible to write a book that will address everyone's needs and keep everyone's interest, I had to limit what I was talking about. This book will be most valuable to someone who is building software, or managing a software project, in a small to medium-size organization where there is not a lot of defined process. If you are in a small company, a start-up, or a small project team in a larger organization, you will benefit most from the lessons in this book. Even if your organization has a very well-defined, heavy process that seems to be impeding progress, you'll be able to use the patterns in this book to focus better on some of the key tasks of SCM.

How To Read This Book

The introduction explains some basic concepts of software configuration management and the notation that the diagrams use. Part I provides background information about SCM and patterns. Chapter 1 introduces the software configuration management concepts used in this book. Chapter 2 talks about some of the forces that influence the decisions you make about what sort of SCM environment you have. Chapter 3 introduces the concept of patterns and the patterns in this book and how they relate to each other. Part II consists of patterns that illustrate problems and solutions to common SCM problems. Chapters 1 and 2 also define the general problems that this book addresses. To understand the how patterns fit together, you should read Chapter 3 to get an overview of the language.

After you have read the first three chapters, you can browse the patterns in Part II, starting with one you find interesting and following with ones that relate to your problem. Another approach is to read the patterns in order and form a mental picture of the connections between them.

The references to the other patterns in the book appear in the introductory paragraph for each chapter and in the Unresolved Issues section at the end of each chapter, using a presentation like this: Active Development Line (5). The number in parentheses is the chapter number that contains the pattern.

Because this is a large field to cover, some of the context and Unresolved Issues sections don't refer to other patterns, either in the book or elsewhere, because they haven't been documented as of this writing. In this case, you will see a description about what a pattern might cover.

Origins of This Material

Much of the material in this book has its origins in papers written for various Pattern Languages of Programs conferences by me, Brad Appleton, Ralph Cabrera, and Robert Orenstein. The patterns have been greatly revised from the original material, but it's appropriate to mention these papers to acknowledge the roles of others in this work: "Streamed Lines: Branching Patterns for Parallel Software Development" (Appleton et al. 1998), "Software Reconstruction: Patterns for Reproducing the Build" (Cabrera et al. 1999), "Configuration Management Patterns" (Berczuk 1996b).

Steve Berczuk
Arlington, Massachusetts, June 2002
steve@berczuk.com http://www.berczuk.com

Why I CoWrote This Book with Steve

I began my software development career in 1987 as a part-time software tools developer to pay for my last year of college. Somehow it "stuck" because I've been doing some form of tool development ever since (particularly SCM tools), even when it wasn't my primary job. I even worked (briefly) for a commercial SCM tool vendor, and part of my job was to stay current on the competition. So I amassed as much knowledge as I could about other SCM tools on the market. Even after I changed jobs, I continued my SCM pursuits and frequented various tool user groups on the Internet.

At one time, I longed to advance the state of the art in SCM environments and kept up with all the latest research. I soon became frustrated with the vast gap between the "state of the art" and the "state of the practice." I concluded that I could do more good by helping advance the state of the practice to use available tools better. Not long after that, I discovered software patterns and the patterns community. It was clear that these folks were onto something important in their combination of analysis and storytelling for disseminating recurring best practices of software design.

At the time, hardly anyone in the design patterns community was attempting to write SCM patterns. SCM is, after all, the "plumbing of software development" to a lot of programmers: Everyone acknowledges that they need it, but no one wants to have to dive into it too deeply and get their hands entrenched in it. They just want it to work and not to have to bother with it all that much.

It didn't take long for me to hook up with Steve Berczuk. We wrote several SCM patterns papers together (with Ralph Cabrera) as part of my ACME project at http://acme.bradapp.net/ and later decided to work on this book. We hope this small but cohesive set of core patterns about integration and teamwork helps the unsuspecting developers-cum-project-lead survive and thrive in successfully leading and coordinating their team's collaborative efforts and integrating the results into working software.

Brad Appleton
Arlington Heights, Illinois, June 2002
brad@bradapp.net http://www.bradapp.net

0201741172P10072002

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 2 Customer Reviews
  • Anonymous

    Posted January 8, 2006

    Excellent¿A wonderful collection of patterns to support team development

    I knew this book would be different from the use of ¿Teamwork¿ in its subtitle. Many of the configuration managers with whom I¿ve worked through the years demonstrated an attitude that was about anything but teamwork. They viewed their job as protecting the source code (and other assets) of a project to the point of getting in the way of the developers. So based on its subtitle, I had very high hopes for this book. I was not let down. This book is excellent. The book starts with a couple of introductory chapters and then devotes a chapter to each of 16 patterns. I really like that the book devotes a full chapter to each pattern (and therefore covers substantial patterns) rather than covering each in two pages as is often the case in patterns books. As a coach and trainer of agile software development teams, I am often asked by these teams how they handle the software configuration management with such fast-moving processes. These excellent and highly readable book has collected a wonderful set of practices and will become a part of the standard canon I recommend to clients.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted January 9, 2003

    Good, well described ideas

    An exceedingly readable book, that is not limited to practitioners of Java. Yes, yes, here and there, the text refers to java files, but it delves no further into the specifics of the language. Rather, the principles described are good, general coding practices, for teams of two or more programmers that want to maximise their efficiency. You could be a C++, C# or even a[gasp] Cobol house, and derive benefit from reading this book. There is minimal use of jargon. The authors appear to have gone to some trouble to make their points as simply and as broadly accessible as possible. One, possibly unintended, consequence is that a tyro programmer may consider this book trivial or vacuous. No complex UML diagrams, no intricate refactoring examples,... It may well be that an experienced old hand might get more out of the book, having endured many an unwieldy or uncoordinated project. Another significant point is that this book is accessible to nontechnical managers. Two scenarios are possible: 1. You are a manager, possibly nontechnical. You want to avoid mismanaging a team of programmers that wants to do things their way. This book might give valuable guidelines; plus you can use it to persuade the team about the logic of your decisions. 2. You are a programmer that is in a project that has had bad management decisions. This book might offer better strategies. Plus, it gives you a way to argue them persuasively to your bosses, even if they are nontechnical.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 2 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)