Many patterns sometimes suggest that the word pattern is just another word for older concepts like work practices or even procedures. Just try substituting the word "activity" in place of pattern and see if the idea still makes sense. That is not to say, however, that patterns have not made a significant contribution to the way we consider and distil our collective experience. The value of patterns is that they are less judgmental than the terminology of the past - their authors more modest. While patterns do, by their very definition, assume general applicability, they are not designed to be prescriptive. Rather, they are more exploratory in nature, suggesting rather than imposing the adoption or instantiation of these patterns in the workplace.

What is most intriguing about patterns however, and what drives some of us to investigate them, is the "discovery" of hidden patterns that are less than obvious and somehow imbued with a deeper significance. An analogy from art and architecture (which first utilized patterns in their search for esthetics rules) would be the recurrence of the Golden Rectangle - said to be one of the most visually satisfying of all geometric forms. It has been identified in a number of great works and its dimensions have  the property that when a square is removed a smaller rectangle of the same shape remains. Although the motivation for, and utilization of Golden Rectangle is much debated [3], the ancients considered it to be of the most pleasing and harmonious qualities that it became known as the divine proportion.

In the software context, what differentiates the analogously subtle and hidden patterns is that, while they might recur like their more mundane counterparts, they possess a symmetry and can be identified at a number of different levels. While they may not have the sense of the sublime that the Golden Rectangle suggests to some, such patterns do hint at deeper significance and offer us a hint of some greater insight - an underlying principle that is yet to be uncovered or completely understood. 

My studies of more general configuration management (CM) applied at different levels of granularity have uncovered one such hidden pattern in concurrent development. In particular, I have been investigating (which could be considered the search for patterns anyway) the correspondence between the "classical" systems-level CM of the early standards and SCM, as defined by the tools and practices software teams use everyday to support the development process. What I have found curious is that concurrent development can be considered a pattern that is equally applicable at the code-level as it is at the coarse-grained, architectural level of system components. Naturally we use a completely different language to describe these things but that is what makes it appear hidden. The intellectual challenge is to consider what underlying property or properties give rise to the pattern, and to compare and contrast the solutions that we apply to these seemingly different situations.

At the code-level we talk about parallel development, where two or more developers are assigned tasks that require them to modify a common file. In some organizations, version control tools are configured to prevent this situation and once a file has been checked-out other developers are blocked from modifying that file until such time as it is checked-in by the original developer. Where parallel development is allowed however, developers can make changes concurrently and check-in their separate versions, creating a branch in the file's version tree that may require the merging of the two versions at some later point.

At the architectural component or sub-system level we no longer talk about individual developers. Instead we might have different customers that place separate requirements on a shared or reused component. Each customer may have a team of developers attempting to satisfy their needs and so we do have the component having to undergo branching [4]. These branches may be temporary, project-oriented configurations that need to be merged later, or more permanent, product variants. Product-lines provide an example of the latter, where two customers can place distinct requirements and priorities that can necessitate a codeline branch that results in a reused component being separately released for each product-variant. So again we have the need to branch, but this time we are branching the entire component's codeline rather than just a single file's version tree. Likewise, there is a need to merge or refactor the different codelines together at some point in the future as failure to do so could destroy the reusability of the component.

Many of you would have experienced the ambiguity in our terminology when discussing concurrent development. Are we talking about parallel effort at the developer-level or at the component-level? There is a need to clarify the level of granularity at which this concurrency is apparent. We do not usually think of a source-file as being reused by the two developers because they usually belong to a single team or product group - yet what happens when more than one team relies on the code? Use of a simple pattern language can help clarify the correspondence between these two scenarios and suggests a symmetry that bears further exploration. The patterns below are described only in overview and are presented primarily to illustrate the similarities at different levels of granularity.

By comparing and contrasting these two patterns that present themselves at different levels of granularity, we can better understand their relationship to each other. By considering them together we can identify the solutions we have in place at one level - and then identify or seek corresponding solutions for the other pattern. For example, why do we have the insulated work-area pattern for parallel development and not a similar construct for a parallel release? Can such an abstraction be valuable? I plan to explore that in a subsequent article.

Deeper consideration of the two patterns can give rise to some interesting insights. They can also help us to clarify our terminology, reducing confusion and inconsistencies. In this way we can recognize sound principles and develop more powerful practices that echo (present strong symmetries) at different levels of granularity. 

By highlighting the symmetries between code-level and release-level scenarios we can begin to understand how the two apparently different interpretations of CM - the common interpretation amongst software developers that focuses on the code-level versus the higher-level, sub-system (or component) focus adopted by the standards - are related.

While SCM practices have traditionally been largely confined to the code-level - primarily because managing the integrity of software code is an everyday challenge and there are numerous tools available to support (and market) the concept - the increasing complexity of software is leading to greater interest in higher-level CM. Focus on project-oriented branching is a relatively recent and been rich ground for developing new SCM patterns. Product-lines and the re-use of architectural components introduce new challenges to CM that cannot be addressed with code-level patterns alone. Software practitioners need to abstract existing SCM patterns so that they are relevant and appropriate in managing increasing architectural complexity.

[1] Berczuk, S., Appleton, S.: Software Configuration Management Patterns. ISBN: 0201741172. Addison-Wesley, November 4, 2002.

[2] Brown, W.J., McCormick, H.W., Thomas, S.W.: Anti-Patterns and Patterns in Software Configuration Management. ASIN: 0471329290. John Wiley & Sons, April 23, 1999

[3] Livio, M., The Golden Ratio : The Story of PHI, the World's Most Astonishing Number. ISBN: 0767908163. Broadway, September 23, 2003.

[4] Appleton, B., Berczuk, S. P., Cabrera, R., Orenstein, R.: Streamed Lines: Branching Patterns for Parallel Software Development, PloP'98 ( )

This article is a sketch of a more rigorous study now being undertaken, which will be published subsequently.