Principia

A change can be viewed in two ways; conceptually or literally. What I mean by this distinction is that when I say the requested change is to “correct spelling mistakes in the poem” I am specifying conceptually what the change is to achieve (and after the fact, what the change achieved). On the other hand we are used to dealing with change in a more literal sense of as set of revisions, for example, “I edited file1 in this change”. In this post I discuss some of the issues and implications of these two views of change.

Let’s put this into concrete terms.

Suppose the original change request is something like, “correct the spelling mistakes in the poem” and the poem is held in two files.

file1.txt contains the following text.

Mary hard a litl lamb,
It's fles was wite as snow,

And file2.txt contains the following text.

And everywere that Mary went,
That lam was sure to go.

 

We correct these two file to the following using a change record CR1.

Mary hard a little lamb.
It's fleece was white as snow

And

And everywhere that Mary went,
That lamb was sure to go.

 

Here then is my first build (build1).

This build has integrity because it contains the content of all valid changes nominated to the build as known at the time the build was constructed, but it is not correct because CR1 fails to satisfy the original request to “correct the spelling mistakes in the poem”.

So, not bad, but the still have “hard” instead of “had” in the first line of file1.txt. This does not change the integrity of build1, but does make another build (build2) necessary to include a correction to the erroneous work submitted into build1.

There are different ways we might choose to track the correction of the defect arising from build1.

Reuse CR1	Regress CR1 to a lifecycle state where the developer can add to it. Allow changes to be associated with CR1, and then resubmit CR1 into a new build. This approach, while simple, may be misleading. When revisiting build1 we need to be sure that we look at CR1 as it was when the build was executed, not as it is after the correction is applied. This can make metrics collection unnecessarily complex.
Create a new change	Treat the defect resolution as a separate change. This could be a new change or a special ‘defect’ record. This has the benefit of keeping track of the revisions that correct the defect in the original change separate to the original change. A feature potentially useful in simplifying metrics collection.
Create a separate but subsidiary change	We create a separate change record to track the specific revisions created to correct the defect, but we relate it to the original change request in a child-parent relationship (the original change being the parent. This has the benefit of keeping track of the specific revisions that correct the defect while maintaining a link to the original change.

Each approach has its own merits but, from the perspective of build integrity, they share an the important feature; when dealing with the conceptual change “correct the spelling mistakes in the poem”, they are semantically equivalent. For build2 to have integrity it must include both the revisions associated with the original change and all new revisions associated with the correction to the change, regardless of how that correction is controlled.

We correct the defect in build1 with an additional change to file1.txt to produce the following.

Mary had a little lamb,
It's fleece was white as snow,

The following illustration shows build2 (in this case I have re-used CR1 to correct the defect). I should be obvious that missing any revision associated with CR1 has the potential to break the build’s integrity (we may have only part of CR1 in the build).

Using a separate change record to control the defect does not really solve this problem, it merely makes it less apparent. Consider the following illustration, it shows the same situation but this time I have used another change record (D1) to control the defect.

Although I can exclude the defect resolution from the build configuration and, in this special case, claim to have maintained build integrity, it is difficult to justify semantically as I have not really included the sum of the conceptual change — the change is supposed to achieve a specific effect upon the system (the spelling correction), something it failed to do with the original literal CR1 in build1 but we hope it does with the combination of literal changes managed by change records CR1 and D1.

And this is the point. Yes, the literal changes CR1 and D1 are, in one sense, changes. In practical terms though each on its own fails to achieve the objective of the original change request and consequently they are little more than sets of revisions. The two literal changes controlled by records CR1 and D1, taken together, achieve the original goal of the change request “correct spelling mistakes in the poem”. It is this latter type of change (what I have called conceptual change) that is more interesting to configuration management and build integrity is maintained through these conceptual changes rather than the less significant literal changes.

This distinction between the conceptual change and literal change becomes increasingly important as we consider configuration integrity, a subject I shall discuss in more detail in subsequent posts.