There are key advantages to having a private workspace for development. The biggest 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’s critical that the private workspace is used in the context of the project and that 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 anti-pattern. 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. A private workspace usually 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 check-in 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). The rate of merging latest into the private workspace or the rate of check-in can be discussed and determined.
What is an Anti-pattern
When talking about what an anti-pattern 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. An anti-pattern is defined as a poor solution. What is meant by that is that an anti-pattern 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 anti-pattern 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 (aka, 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 “Anti-Patterns of Change Control” by Mario Moreira (October 2004).
How Anti-Patterns Impact Private Workspaces
As mentioned previously, the ability to work in isolation makes a private workspaces very beneficial to programmers. It is important, however, 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 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.
Below are three examples of poor results (aka, anti-patterns) in relation to private workspaces, though more can certainly be identified.
Anti-Pattern 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.
Anti-Pattern 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.
Anti-Pattern Name: Workspace Clutter
Problem
· I need to prototype or test several scenarios of changes in my workspace.
Context
· No SCM Checkout/Check-in 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 clean up 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 it’s time to submit the changes to the project integration stream (aka, 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, as the changes work in the programmer’s private workspace.
Better solution
· Establish a step in the SCM checkout/check-in 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.
Anti-Pattern 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 (aka, 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 (aka, 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 (aka, 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/check-in process including merge steps. Educate programmers on this process.
Summary
Discussing anti-patterns 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 is 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 anti-patterns discussed above will help you avoid common mistakes.
References
1. “Approaching Continuous Integration” by Mario E. Moreira, article on CM Crossroads, September, 2004
2. “Anti-patterns of Change Control” by Mario E. Moreira, article on CM Crossroads , April 2004
3. "Software Configuration Management Implementation Roadmap" by Mario E. Moreira, 2004, John Wiley & Sons, Ltd
4. Anti-patterns and Patterns in Software Configuration Management by William J. Brown, Hays W. “Skip” McCormick III, and Scott W. Thomas, 1999, John Wiley & Sons, Ltd
5. Software Configuration Management Patterns: Effective Teamwork, Practical Integration by Stephen P. Berczuk with Brad Appleton, 2003, Addison Wesley
6. The Anti-pattern section of theWiki Wiki Web - see http://c2.com/cgi/wiki?Processanti-patterns
