There are key advantages of having a Private Workspace 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 antipatterns is valuable in constructing actual working processes that fit the working environment.

In particular, understanding the concepts of antipatterns 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 Antipattern 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.  

Figure 1: Context of a Private Workspace

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.

An antipattern will appear when a solution is decided and deployed, but the context and forces are not factored in and consequences of the solution are not considered.   The context and forces are critical input prior to defining a ‘good’ solution (a.k.a., pattern).  By context, this refers to the setting or experience level of the organization in which the problem lives and in which the solution must work.  By forces, this refers to various influences in play (political, procedural, social, resistance, maturity, etc.) that can affect a solution and therefore the solution’s ability to be adopted.  Note: this section adapted from a section in the article “Antipatterns of Change Control” by Mario Moreira (October 2004).  

How Antipatterns impact Private Workspaces

As mentioned, the ability to work in isolation makes a private workspaces very beneficial to programmers.  However, it is important that the private workspace is used in the context of the project and the forces influencing the project and programmer are understood.  While private workspaces can be very advantageous, it is important for those who own the development process to discuss the usage of the private workspaces in relation to the expected change rate, release schedule, and other factors.  Otherwise, programmers can use the private workspaces leading to poor results.        

Private Workspace Antipatterns

Below are three examples of poor results (a.k.a., antipatterns) in relation to Private Workspaces.  More can certainly be identified. 

Antipattern Name: Isolationist

Problem:

• How often should I populate my private workspace with the latest changes?  

Context:

• Project development methodology (waterfall, incremental, iterative) is not identified or understood.  
• No direction or guidance provided on the rate of change to a workspace.   
• Do not really understand the meaning and full implications of continuous integration.  

Forces:

• Some programmers like to work in isolation.  No one bothers them and they do not bother others.     
• Programmers get more work done with they do not have to deal with changes occurring underneath.
• Because private workspaces come with a separate branch or stream and versioning, a programmer can ensure their code is backed up.  However, this can give the perception that they can keep their changes private longer. 
• Changes to the latest baseline often force them to do a lot of rework.       

(Poor) Solution:

• Infrequently update the private workspace with latest code baseline.

Consequences:

• When it is time to deliver changes, a potentially large merging and reconciliation (changes, building, unit testing) task may be needed which could take a while, possibly affecting the release schedule.  In addition, other programmers have not seen the changes and this can impact past project changes causing regression and breakage in the code.   

Better Solution:

• Ask for a clear understanding of the project development methodology (waterfall, incremental, iterative) and a general expectation of the frequency of updating the private workspace with the latest baseline. 
• Update the private workspace after reaching a milestone of change (fixed the defect, completed one change request, etc) that aligns with the change frequency expected and the development methodology used. 

Antipattern Name: Cool to be Continuous

Problem:

• How often should I populate my private workspace with the latest changes?  

Context:

•  Project development methodology (waterfall, incremental, iterative) is not identified or understood
• No direction or guidance provided on the rate of change to a workspace.   
•  Do not really understand the meaning and full implications of continuous integration and how to best apply it.     

Forces:

• Riding the latest trend (e.g., continuous integration wagon) is cool.   
• Need something to blame for slow progress in programming.

 (Poor) Solution:

• Constantly update the private workspace with latest code baseline irrespective of readiness to accept changes.

Consequences:

• Can never (or hardly ever) complete a change request or fix a problem in the code since the baseline of code surrounding the change continuously is updated.  Progress is very slow. 

Better Solution:

• Ask for a clear understanding of the project development methodology (waterfall, incremental, iterative) and a general expectation of the frequency of updating the private workspace with the latest baseline. 
• Update the private workspace after reaching a milestone of change (fixed the defect, completed one change request, etc) that aligns with the change frequency expected and the development methodology used.

Antipattern Name: Workspace Clutter

Problem:

• I need to prototype or test several scenarios of changes in my workspace.  

Context:

• No SCM Checkout/Checkin or Build process/procedure exists that addresses private files.    
• The private files come in handy.    

Forces:

• For prototyping and testing, people can easily (and without anyone else knowing) create a private file or copy an existing of a source file within the workspace.
• Sometimes people forget to cleanup the private files.  

(Poor) Solution:

• Allow people to create private files and keep them in their private workspace as long as they want without any governance process of managing them.    

Consequences:

• When its time to submit the changes to the project integration stream (a.k.a., Active Development Line), only the checked out files are checked in and submitted, therefore missing the potentially needed private files.  The needed private files cause the project integration stream build to break.  The corrective action may be difficult to identify since the changes “work” in the programmer’s private workspace.     

Better Solution:

• Establish a step in the SCM Checkout/Checkin or Build process/procedure to remove or cleanup the private files prior to file builds and unit tests with a private workspace. Educate programmers on these processes.
• Establish a consequence (e.g., reprimand from product manager) for the programmers who do not cleanup appropriately and cause build and regression problems.        

Antipattern Name: Lazy Merge

Problem:

• Where do I merge my code with the latest code in the project integration stream (Active Development Line)?   

Context:

• The programmer has made changes in the private workspace and is ready to move it to the project integration stream (a.k.a., Active Development Line). 

Forces:

• The programmer has a list of new work changes they must start.  
• The release date is getting closer and the pressure is building to get the changes in. 
• The merge process is not well defined and understood.     

(Poor) Solution:

• Merge the changes to the project integration stream (a.k.a., Active Development Line).

Consequences:

• When merging to the project integration stream, any changes to code in this baseline are not tested (or rebuilt) to validate that the changes still integrate well with the full baseline of code. 

Better Solution:

• Merge the changes (e.g., take the latest code) from the project integration stream (a.k.a., Active Development Line) into the programmer’s private workspace first.  Then reconcile (e.g., rebuild, retest).  This will ensure that the programmer’s latest changes do not break the latest baseline of code which everyone depend.
• Establish clear guidance in the SCM Checkout/Checkin process including merge steps.  Educate programmers on this process.      

Summary

Discussing antipatterns is a useful way to evaluate possible solutions.  By considering the context of the problem and the forces that are in existence, it provides a way to evaluate the potential solutions and identify which is best for the given situation.    

With this in mind, it is important that the private workspace be established in relation to an overall development process.  Assess the context of the project and the forces influencing the project and programmer.  Design, document, and communicate the development process and the usage of the private workspaces in relation to the expected change rate, release schedule, and other factors.  While the concept and working model of a private workspace can be very advantageous, I hope the antipatterns discussed above help you avoid common mistakes.

References

• “Approaching Continuous Integration” by Mario E. Moreira, article on CM Crossroads, September, 2004
• “Antipatterns of Change Control” by Mario E. Moreira, article on CM Crossroads, April 2004
• “Software Configuration Management Implementation Roadmap” by Mario E. Moreira, 2004, John Wiley & Sons, Ltd
• “AntiPatterns and Patterns in Software Configuration Management” by William J. Brown, Hays W. “Skip” McCormick III, and Scott W. Thomas, 1999, John Wiley & Sons, Ltd
• “Software Configuration Management Patterns: Effective Teamwork, Practical Integration” by Stephen P. Berczuk with Brad Appleton, 2003, Addison Wesley
• The Antipattern section of the Wiki Wiki Web - see http://c2.com/cgi/wiki?ProcessAntiPatterns

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment