Anti-Patterns of a Private Workspace

Summary:
There are key advantages of having a private porkspace for development. With this in mind, it is critical that the private workspace is used in the context of the project and the forces influencing the project and programmer are understood. Understanding the concepts of anti-patterns and how they can disrupt the adoption of good practice will lead to establishing practices that fit within a group.

There are key advantages of having a private porkspace for development. The biggest advantage is that you can work in isolation from other changes around you. It is important to understand how the private workspace is used so that it is managed in the best way possible. With this in mind, it is critical that the private workspace is used in the context of the project and the forces influencing the project and programmer are understood. This is where the study of patterns and anti-patterns is valuable in constructing actual working processes that fit the working environment.

In particular, understanding the concepts of anti-patterns and how they can disrupt the adoption of good practice will lead to establishing practices that fit within a group.  For example, if there is a very ambitious Quality Manager who thinks they can introduce CMMi Level 5 without first understanding the culture of the company in adopting such practices, the effort will be short lived.  If the company has had poor results in even understanding a process and operates ad hoc (CMMi Level 1) and there is no reward system for adoption of CMM, then the forces currently in play within the organization will likely lead this effort to become low priority (or people will avoid them) and ultimately fail to take root.

Defining an Anti-pattern and Private Workspace
It is important to have a consistent definition of what is a Private Workspace and what is an Antipattern.

What is a Private Workspace
A private workspace is an isolated place where software programmers can control the versions of code they are working on.  Typically, a private workspace lives in the context of a code development process.  The code development process includes an “active development line” which is a place where the latest baseline of code resides sometimes known as the “project Integration” stream or branch.  Connected to the project integration stream are the private workspaces.  To illustrate this, please review the “Figure 1”.    Private workspaces are individual streams of development where each developer can work on his/her own code changes independent of the latest and continually changing baseline of code in the project integration stream.  

In order to determine the best development process in which a private workspace lives, one must first understand the nature of the development project and the development methodology, amongst other factors.  For example, the rate at which a programmer should bring the latest code from the project integration stream to the programmer’s private workspace may be dependent on the development methodology (iterative vs. incremental vs. waterfall), the size of the team, and the release schedule.  In addition, the frequency of the checkin is dependent on these factors.  In other words, the development methodology should be understood, the release cycles should be known, the number of programmers of the team,  and what they work on (requirements and defects) should be clear (amongst other factors).  From this, the rate of merging latest into the private workspace or the rate of checkin can be discussed and determined.     

What is an Antipattern
When talking about what an ‘antipattern’ is, we must also address what a ‘pattern’ is.  A very simple definition of a pattern is that it is a ‘good’ solution with the implication that the solution actually works within the context and forces of the organization or group.  Ergo, an antipattern is defined as a ‘poor’ solution.  What is meant by that is that an antipattern is a solution to a problem that may appear like a good idea, but lacks the necessary input to make it effective and workable.

About the author

Mario  Moreira's picture
Mario Moreira

Mario Moreira is a Columnist for the CM Journal, a writer for the Agile Journal, an Author, an Agile and CM expert for CA, and has worked in the CM field since 1986 and in the Agile field since 1998. He has experience with numerous CM technologies and processes and has implemented CM on over 150 applications/products, which include establishing global SCM infrastructures. He is a certified ScrumMaster in the Agile arena having implemented Scrum and XP practices. He holds an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience. Mario is the author of a new book entitled “Adapting Configuration Management for Agile Teams” (via Wiley Publishing). It provides an Agile Primer and a CM Primer, and how to adapt CM practices for Agile Teams. Mario is also the author of the CM book entitled, “Software Configuration Management Implementation Roadmap.” It includes step-by-step guidance for implementing SCM at the organization, application, and project level with numerous examples. Also consider visiting Mario’s blog on CM for Agile and Agile adoption at http://cmforagile.blogspot.com/ . You may reach Mario by email at Mario.Moreira@cmcrossroads.com.