SCM tools are not configuration management tools

The main reason why most so-called SCM tools are not really SCM tools is because they don't support managing software configurations. Making software is more than writing source code and converting them into executable code and data models for databases. A real SCM tool would be able to capture everything that is important for deploying and maintaining the software. This includes requirements, designs, models, sources, tools, infrastructure, knowledge, skills, test scripts, test data, manuals, scripts and other information.

Most SCM tools are able to capture files in a structure and control changes to the files and the structure. New files and new versions of existing files are all merely new files. Typically, the structure is 3-dimensional:

• Directory (or folders) structure
  
• Version (or revision) structure
• Branching structure
  

The directory structure may seem to be a 2-dimensional structure (i.e. nested directories and directory next to eachother at the same nesting level), but if we consider the pathname + filename as the single identifier for a file, then the directory may be considered as 1-dimensional. The version structure is 1-dimensional: the successive versions supersede their predecessors. How about parallel versions? Parallel versions are partial contributions to a single succesor version. The actual successor is a merge of these partial contributions. Branches look similar to parallel versions, but the essential difference is that parallel versions are partial contributions to a single successor while branches are full contributions (version structures) to alternative successors.

If we look at the implementation of these dimensions, then the most simple implementation is 1-dimensional: all 3 dimensions are projected onto the same implementation, e.g. as directory structure (or path+filename). The "version control tool" could be an ordinary file system. For example:

main/gui/generic/foo-v1.c
main/webgui/unix/foo-v1.c
main/webgui/unix/foo-v2.c
main/webgui/unix/foo-v3.c
main/webgui/winxp/foo-v1.c
main/webgui/winxp/foo-v2.c
R1.0.0.0/gui/generic/foo-v1.c
R1.0.0.0/webgui/unix/foo-v2.c
R1.0.0.0/webgui/winxp/foo-v2.c

The problem with this version control system is that path+filenames changes for every new version. So users and the build process have to do more work to figure out which version they should us.

The next better implemention would be a 2-dimensional implementation: directory and branching are combined into a single dimension (path+filename), and versioning is the other dimension. Simple version control tools like Subversion works this way. For example:

main/gui/generic/foo.c (versions: 1)
main/webgui/unix/foo.c (versions: 1, 2 and 3)
main/webgui/winxp/foo.c (versions: 1 and 2)
R1.0.0.0/gui/generic/foo.c (versions: 1)
R1.0.0.0/webgui/unix/foo.c (versions: 2)
R1.0.0.0/webgui/winxp/foo.c (versions: 2)

Advantage is that the path+filename remains the same for all versions within a branch. But for different branches, the path+filename is different. And since directories and branches are resolved in the same dimension (the path), it is not possible to distinguish between a directory and a branch. For example, are main and R1.0.0.0 different branches? Are unix and winxp different branches? Are gui and webgui different branches? Or are they different directories within the same branch? So users have to make agreements about naming conventions to distinguish between branches. The SCM tool only takes care of deciding (automated) which version is used.

One step further is a 3-dimensional solution, where directory (path+filename), version and branch are independent of each other. More advanced version control tools like ClearCase or Synergy are needed. For example:

gui/foo.c (versions: 1 on branch: main)
webgui/foo.c (versions: 1 and on branch: main; versions: 2 and 3 on branch: unix; versions: 2 on branch winxp)

Advantage is now that the path+filename remains the same for all versions and all branches. This simplifies the implementation of an automated build process and the description in design documents and models. But the counterside is that SCM has to have the information to decide which branch a user is working on in order to select the correct version for the user to work on. And the user may be unaware of the branch he is working on - introducing the risk that he is working on the wrong branch.
So on one side SCM makes life easier for the user and the organization (e.g. automation), but on the other side it introduces extra work to reduce the risk mistakes or to repair them.

As you can see, I have left out the baseline (R1.0.0.0) from the last example. In the first and second example (1 and 2 dimensional), the baseline was combined with the directory dimension. In the last example, the baseline could be combined with the branch dimension, but it could also be implemented as a 4th dimension: labeling or tagging.

And this brings me to the point where version control enters the domain of configuration management. An essential feature of configuration management is to identify dependencies. A dependency defines which objects belong together. There are many different dependencies that can be (or need to be) identified, for example:

• Directory dependency: all files within the same directory tree
  
• Branch dependency: all files on the same branch
• Version dependency: all latest versions
  
• Status dependency: all files with the same status (e.g. release R1.0.0.0)
• Content dependency: all files with compatible content (e.g. requirements-design-code consistency)
  

The status dependency is typically modeled in a so-called promotion model. All files go through a predefined series of statuses, and files (versions) with similar status and context (e.g. branches, directories) belong together as a configuration. These statuses are for exampe: working, integration testing, system testing, released. Tools support promotion by branching (e.g. ClearCase/UCM by deliver and rebase, or Subversion by "smart" copying of directories called branching) or by selection rules (e.g. Synergy by reconfigure property templates).

But one of the biggest shortcomings in SCM tools that I know is the absense of support for content dependencies. How do you identify the impact of the change of the design on code, requirements and tests? How do you identify the impact of code changes on other code, interfaces, design models? How to maintain the content information efficiently? How to you know that the content dependency is compromised? How do you know that release 3.2 of product X does work with release 1.2 of the framework, but not with release 1.1 of the framework? How do you know that release 6.1 of product Y cannot work with product X because it does not work with framework 1.2?

Another big shortcoming of SCM tools is that they only support control on file level. They don't control requirements, components in the design model, test cases in a test specification, tool versions (e.g. compilers, IDEs, webservices), hardware versions (e.g. 32-bit architecture). Consequently, many organizations try to capture those items in files, e.g. by creating a requirement specification document that "baselines" a set of requirements. But then again, those individual requirements - although versioned in a requirement management tool - cannot be identified as separate objects in the SCM tool, let alone that dependencies on requirements level can be identified or that individual requirements can be identified to a baseline.

The only solution that I am aware of that comes close to an "SCM tool" is the Jazz platform, starting the Rational Team Concert, but integrated with the requirements, test and project management applications. Since all information is stored in a composite repository, where information objects are actually identified as objects (not as files), it becomes possible to identify relationships (such as dependencies) between objects (not only files). Yet, I doubt whether it will be capable of identifying dependencies between configurations, e.g. content dependencies between software packages.

Writing a book like developing software

In the article Writing a book is like developing software, Roy Osherove compares writing a book with writing software. Now let's assume that we would write books like we develop software.

Most books are written by a single author. Take for instance The Lord of the Rings by J.R.R. Tolkien. Suppose we would take up the assignment to write a sequel of this bestseller, but develop it like a software product. Suppose some of the requirements are

• It must appear on the market in English, Spanish and Russian simultaneously
• It must appear before Christmas 2007
• It must equal or exceed the success of the current books

Given the short timeframe and the limited available of talented and experienced writers (scarce resources), we decide to write the book in as multisite project. We set up and English team in the America, a Spanish team in Europe and a Russian team in Asia. Given the global distribution, we can work round the clock.
To reduce intercontinental communication across timezones, we will assign different parts of the book to each team. Each team will write in its native language to assure the highest quality of writing. When one team finishes a part (or a preliminary version of it), it will be sent to the other teams for verification and translation.

The verification process will compare the story with the requirements. Which requirements? How do you make "exceed a previous success" SMART, if you cannot sell the book before finishing it? This is a job for marketing. They have to verify if the book will sell good enough.

We were talking about assigning parts to different teams. Which parts? If we divide the book into chapters, we can assign a chapter to a team. Which chapters will we have if we don't have the story yet? But the story is to-be-developed by the team. To divide into chapters we need the overall plot, in abstract form. But, who is responsible for the overall plot?

Okay, division into chapters seems to be a bad idea. Let's divide into characters (persons in the story), and assign different characters to each team. May be the cultural background of each team may even be an advantage for writing and for the overall result. But how can you write a story of characters in separate teams, if there is not plot that connects those characters? Characters need to interact in the story. Furthermore, different teams will be writing simultaneously on the same part of the story. So we need to integrate parallel updates, and we need to review the different story elements before integrating them.

Another issue is that during the story, we build up a history. If for example two characters meet in the beginning of the book and become friends, they cannot be complete strangers and enemies lateron.

Sigh! We need a story architecture that defines the development of characters and the development of time (history) across the whole book. It also defines the characteristics of the characters, the landscapes they visit, timing constraints (e.g. you cannot be at two different places in the same timeframe).

And we need configuration management to assure that the correct versions are reviewed, verified and translated. Especially translation is a dangerous one: if you translate an old Spanish section to Russian, the English and Spanish teams will not discover it because they cannot read Russian, except the people who translate from Russian. But why would a Spanish translator be bothered with reading a section that was originally in Spanish? So, CM must assure correct version and status handling.

I can go on and on, but probably you have lost faith that a book written this way will (1) be ready before Christmas 2007 and (2) exceed the success of The Lord of Rings. Yet, many companies develop their (software) products in multisite projects, with teams in America (US, Canada), Europe (UK, France, Germany, the Netherlands), Asia (India, China, Singapore), and without proper configuration management - except branched version storage and multisite replication.

Is multisite book-writing a good idea? And multisite software development?

Are modeling languages useful for complex systems?

In the August edition of the Rational Edge, Laurance Balmelli gives an introduction to the basic purpose and value of Systems Modeling Language (SysML), a proposed extention to the Unified Model Language (UML). An interesting article where he uses a simple system (Rain Sensing Wiper in a car) to explain some basic concepts about requirements modeling with SysML.

Reading through it I noticed that although it is a simple system to regard, it still requires a decent model to describe it. I was wondering how this would be for complex, real-time systems like cars, airplanes, shpace shuttles or medical imaging equipment. Those systems are so extensive and so complicated, that the requirements model will probably at least as difficult to comprehend as the system that is being modeled. But the purpose of the model is to make the system's functionality (and non-functional aspects) easier to understand that just using your (expert) vision based on years of experience with developing those kind of things.

If modeling the monster is about as difficult as comprehending the system without the model, then why bother? In practice, you do often see that modelling is only used to get an initial vision of functionality and architecture because no one has enough experience to build an intuition. But after several years of developing release after release, the models start to get out-of-sync with the implementation and the documentation. I see it all the time that first models are neglected and the modelling tools are degraded to drawing tools.

Does this means that the modeling languages (like SysML) serve no purpose for those large and complex systems? I think they do partially. As long as these modeling languages (even when they are visual languages) are general and very abstract, engineers with a lot of experience and with a specific and concrete mental picture of the system will probably outperform the modeling language. But once those modeling language are more dedicated to the application area, either by design or by heuristics that allow the language to adapt to the application area, I think those languages may become a more practical tool for extreme complex systems. It's a matter of being able to trust the models to be more reliable than the mental pictures of the engineers.

Update 14/4/2007:
Added labels.