Defining: Baseline

Last night I sat in a bar and watched the [NBC Sports][] presentation of the opening ceremonies of the Torino 2006 winter Olympic games. I didn’t want to, mind you, but every one of the nine TVs in my local [T.G.I. Friday's restaurant][] were set to the same broadcast. My problems with this are two-fold. First, the ceremonies are just insane. If you saw them, you know what I mean. If you didn’t see them, picture this: people in skin-tight suits, skating in circles, wearing backpacks from which flames are shoot into the air. You might say “WHAT?!?!” I did.

[NBC Sports]: “NBC Sports’s Olmpics coverage”
[T.G.I. Friday's restaurant]:

Second, the Olympics are being presented by NBC. I’ve seen this before, and it wasn’t done well. I acknowledge that there is a certain jingoism associated with presenting international sports to an American audience. (And likewise if you’re a broadcaster in Australia or Senegal.) But I also believe that NBC has just completely lost it. There are millions of Americans who pay good money to watch hockey on cable, or to sit in a bar or restaurant and watch it. So why, oh why, would you ignore the hockey finals in favor of watching some American compete in the early rounds of a sport that few people know is a sport, and none really care about? “Why, because they’re American, of course!” But someone, somewhere, must have made the decision that sports fans aren’t watching–only red-necked, xenophobic idiots. Thanks, guys, I respect you, too.

I tell you all that so that I can make this single, trivial point: I’m not going to watch the Olympics. And I’m not going to use an Olympic metaphor in the next paragraph. I’m going to use a “real sports” metaphor, instead. I’m sorry the introduction took so long, but, please, read on and enjoy.

A long time ago, on the [SCM Patterns mailing list][] (run by [Brad Appleton][] –one of the most useful guys in public CM discourse), the discussion turned to defining terms. Today, I’m going to (pay attention, NBC programming wonks) pick up that ball and run with it. The word for this article is ‘baseline’. It’s pretty fundamental to what we do on a day-to-day basis, so I think it’s worth exploring.

[SCM Patterns mailing list]:
[Brad Appleton]:

### Baseline ###

A baseline has as its key characteristics that it is “known” and “fixed” in both time and value. Consider the following [definitions][]:


Field of Endeavor Definition of ‘baseline’
Healthcare Information gathered at the beginning … from which variations are measured.
  A known value … with which an unknown is compared when measured or assessed.
  The initial time point … reference point.
Project Management An imaginary line or standard by which things are measured or compared.
  A quantitative expression of planned costs, schedule, and technical requirements for a defined project.
Sports The line defining each end of the court; also known as the “end line.”
  A baseline is the direct route–a straight line–between two adjacent bases.
Statistics Accurate, quantitative data at a stated point in time that marks the beginning of a trend.
  Data on the current process that provides the metrics against which to compare improvements and to use in benchmarking.
Typography An imaginary line that most characters in a typeface rest upon.
  The line on which the bases of capital letters sit.
  … the line upon which most letters “sit” and under which descenders extend.

Most etymologies point out that the term ‘baseline’ derives from its use in surveying. So pay particular attention to these “original” meanings:

Surveyal In United States land surveyal, a baseline is the principal east-west line that divides townships between north and south. The baseline meets its corresponding meridian at the point of origin for the land survey.
  The east-west survey line in public domain states.
  In Canadian land surveyal, a base line is one of the may principal east-west lines that correspond to 4 tiers of townships (2 tiers north and 2 south). Each base line is about 24 miles apart, with the first base line at the 49th parallel, the western U.S.-Canadian border.
  (GPS) The difference in three-dimensional coordinates (X, Y, Z) computed from the difference in simultaneous carrier phase observations at two or more receivers.

Here are some attempts to define ‘baseline’ specific to the CM field. This is the last set of definitions before the “good parts.” Take that as a promise or a warning, your choice.

Configuration Management A baseline is an approved configuration item, e.g., a project plan that has been signed off for execution.
  The point at which some deliverable produced during the software engineering process is put under formal change control.
  A named set of object versions which fixes a configuration at a particular point in time. A baseline normally represents a milestone or key deliverable of a project.
  The “Allocated Baseline” is the initially approved documentation describing an item’s functional, interoperability, and interface characteristics that are allocated from those of a system or a higher level configuration item, interface requirements with interfacing configuration items, additional design constraints, and the verification required to demonstrate the achievement of those specified characteristics.
  The “Configuration Baseline” is (1) An agreed-to description of the attributes of a product, at a point in time, which serves as a basis for defining change; (2) An approved and released document, or a set of documents, each of a specific revision, the purpose of which is to provide a defined basis for managing change; (3) The currently approved and released configuration documentation; (4) A released set of files comprising a software version and associated configuration documentation.
  The “Functional Baseline” is the initially approved documentation describing a system’s or item’s functional, interoperability, and interface characteristics and the verification required to demonstrate the achievement of those specified characteristics.
  The “Product Baseline” is the initially approved documentation describing all of the necessary functional and physical characteristics of the configuration item and the selected functional and physical characteristics designated for production acceptance testing and tests necessary for support of the configuration item. In addition to this documentation, the product baseline of a configuration item may consist of the actual equipment and software.

Before we dive into the CM-related definitions, let’s go back and look at the surveying definitions. Returning to our roots is usually a good idea, especially when we’re not completely sure what’s what. Ignoring the GPS-related definition (too new) and the reference to “public-domain states” (it echoes the first definition) we are left with two very precise, very different usages: one from the United States and one from Canada. There’s a joke there, but it’s too easy.

### Surveyal: why did only the U.S. and Canada do it? ###

What the two remaining definitions have in common is this: unlike Europe and Spanish America, the western parts of the U.S. and Canada were settled in a time when surveying was considered to be a precise, unambiguous, scientific method for rigorously establishing location. Before this time, property boundaries were established by the “deed method,” which involved a walking circuit of the boundaries complete with descriptions and references to landmarks:

> From the west side of the stream, even with the great oak tree, west northwest
> about 200 paces to a large rock. From the rock south more than 450 paces to a
> hillock with three spruce trees in a triangle about 10 paces across. From the
> westernmost spruce tree east 100 paces to the stream, where a pole has been
> erected marking the boundary. From the boundary pole north along the center
> of the stream to the starting point.

This had quite a few faults, not least of which was the temptation of a neighbor to move a rock or pole if something was to be gained by it. (Make your own joke here about project managers.) Having suffered this on their own, and having come from European countries where their ancestors had suffered this for centuries, the early U.S. and Canadian citizens gladly adopted surveyal as a precise way of dividing their terrain. The Europeans had long-established property deeds. The science of land survey was not invented when they began dividing up their land, so they were stuck with the old way.

The other significant territory that might have benefited from surveyal was of course India. While the British did a magnificent job of surveying a truly enormous terrain, I have found no reference to the kind of detailed allocation of property done by the U.S. and Canada. I suspect this may have to do with the Indian history of feudal rule: when the guy on top owns everything from one horizon to the other, there isn’t much incentive to measure it in square-mile plots. (If you have information, or better still references, on the fine-grained measurement of property in India, I would love to hear from you. Was there any such project?)

### Surveyal: what’s a baseline? ###

The key measuring act in surveyal is triangulation. It turns out this is a fairly simple, easy-to-grasp problem in geometry that is made stunningly difficult by interference from the physical world. First, the sum of angles in a triangle is not 180° because it’s on a sphere, not a flat surface. Second is the need to know the altitude of the land on which the measure is taken. Third is the distortion (especially of vertical angles) caused by the atmosphere. Again, it’s a simple task that happens to be really, really difficult to do well.

As a result of this, it’s useful to have a set of known points. These known points are established by diverse measurements. Astronomical readings are taken for multiple stars, across a long period of time (to average out atmospheric distortion). Canals or wells are dug to establish altitude above sea level (or to serve as a common “local water level”). Bearings from landmarks whose locations are well known are taken, again over a long period of time. The end result of this is the establishment of two very well localized points. The short, straight path between these two points is a baseline.

The Canadians made their baselines frequently occurring: every 24 miles. It seems a safe bet that the surveyors didn’t spend an entire year establishing the location of each one. In the U.S., on the other hand, there is one baseline *per state.* These lines might have been more definitive, although there were far fewer of them (so the derived property lines probably lost accuracy).

The upshot of all this, though, is that a baseline is a line–literally, a line–whose location is really, really well defined. That line serves as a known quantity from which other computations can be derived: in India, baselines served as the anchors for the chains of triangulation that established the [Great Arc] and served as the basis for all maps; in the Americas, baselines became the basis for individual ownership of land.

[Great Arc]:

In surveyal, recall, lines are products of art. The very object of modern surveyal is to create lines: lines to demark property, lines to divide nations, lines to run railroads. Surveyal is, if you will, the science of line-drawing. It should come as no surprise then that a baseline, one of the most important elements of triangulation, is an actual line. If surveyal were based on drawing arcs, or circles, then the well-measured elements might be called base-arcs, or base-rings. (‘Keyrings’ would be too tongue-in-cheek, even for me.)

The “line” part isn’t really relevant. It’s a useful place-holder for whatever we’re talking about, especially if that happens to have line-like qualities. But the crucial part of the baseline definition isn’t the “line,” but rather the fact that a baseline is a line from which other lines of lesser import are derived. Furthermore, if the derived lines are found wanting the baseline is generally not questioned. In case of error, we assume the baseline to be correct and look for fault in the way the other lines were derived.

### Baselines from other fields ###

Looking back at some of the other definitions we can see that some of them are very apropos, while a few are either homonyms with poor pedigree or over-refined, in-breeds that have lost their connection. The common understanding of a baseline as a known, shared reference from which work is begun or from which differences are measured shines through.

One interesting aspect of how baselines are understood is the subtle difference between “starting point” and “reference point.” In particular, look back at the definitions supplied by the statistics and healthcare communities (although I suspect that the healthcare definitions are derived from the statistics used in clinical studies). The sense of baseline in those entries is as applied to an irreproducible entity (patient) or situation (present day). The feeling I get is that the baseline is “everything we can possibly record about what we’re studying, because we have no hope of reproducing it.” This is in strong contrast to the way I, and many others, view software CM. In CM, being able to reproduce our baselines is fundamental. If you can’t reproduce something, then it surely wasn’t a baseline, was it?

I wonder if this is correct, though? I mean, look at what the statisticians and health-care workers are doing: describing something in as much detail as possible without the hope of being able to reproduce it. There’s no hope whatsoever that your doctor can reproduce what you were like yesterday, far less ten years ago. There were a bunch of movie star cloning jokes. Make your own joke here involving “Pamela Anderson” and “Functional Baseline”.

What would we call such a thing in the software or hardware CM world? A detailed description of a configuration item that could not possibly be used to reproduce it. Is that, in fact, a baseline of some kind? There’s a lot to be said for the notion that it is. If you look back at the various CM definitions for baseline, all the various baselines are defined in terms of documentation describing various aspects of the CI. Only at the last, as an afterthought to the definition of Product Baseline, do we see this:

> In addition to this documentation, the product baseline of a configuration item
> may consist of the actual equipment and software.

I think that many of us–and I know that I’m guilty–have simply made the leap that tool vendors have encouraged us to make: the software is the baseline. The circuit diagram is the baseline. You can reproduce software exactly from the tool, so there you go! Let the identifier in the version control tool, or the document id in the PDM tool, be your baseline.

But is it?

### What is a baseline for? ###

Looking back at the various definitions, and at the “essential meaning” I extracted from them, I claim that a baseline is a known, shared reference from which work is begun or from which differences are measured. Fine. But what are we talking about?

We’re talking about the difference between “the detailed drawing is the baseline” and “a baseline is an agreed-to description of the … product, … to provide a defined basis for managing change.” Do we need a semantic baseline to measure the difference?

Let’s consider one of a thousand products on the market for software developers. I’m sure there are similar, if maybe fewer, products for the hardware market, but my background is software. This product, [Code Visual to Flow Chart][], I’ve chosen because it was the first Google response to “automatic flowchart” that didn’t involve the word “Cobol.” Sorry, but I do have my standards.

[Code Visual to Flow Chart]:

I have no idea if the thing works. I have no desire to find out if it does, or doesn’t. I hate flowcharts. But here is a tool that, so the author claims, can generate flowcharts from source code. Let us suppose that we have a few million lines of C++ laying about, and let us further suppose that the author’s claims are 100% correct: the tool does generate accurate flowcharts from source code.If I feed the source code into this tool, presumably I’ll get thousands of image files, each containing a flowchart image. If I print out all those thousands or images, or paste them into an [OpenOffice][] document, does that constitute a baseline for the software?


I’ll agree that it is a baseline–in fact, it’s a better baseline than copies of the source code–but only on a technicality. It’s the same technicality that the CM tool vendors have been trying (and succeeding) to catch us with: an incredibly detailed image of the thing is, obviously, an incredibly detailed description of the thing, and therefore a baseline.

But I argue only for the technicality–that it fits the letter of the definition of a baseline without fitting the spirit. Because the description of a thing is supposed to be an aid to comprehending its nature. The many [definitions of description][] seem to agree that a description attempts to represent the nature and characteristics of a thing using words. I’m willing to forego the “using words” part, since pictures (even flowcharts) can be useful in comprehension. But I’m not willing to substitute a copy of a thing, even a blueprint of the thing, for the description.

[definitions of description]:

Consider “Ulysses,” by James Joyce. A giant tome, popular with sadistic secondary school and university teachers, it weighs in at between 800 and 1000 pages, depending on the form. It is written in stream-of-consciousness style, and follows its protagonist through the course of a single ordinary day. It was first published in serialized form between 1918 and 1920 in The Little Review, an American journal. The first print edition was in 1922. It has been the object of much controversy, including an obscenity trial, but at present it is regarded as a masterwork of Modernist writing.

*That* is a description. It was taken from the [Ulysses WikiPedia entry][], except for the slant, which comes from my own tormented high school memories. Notice that I did not feel obligated to include the full 267,000 words: there was no need. The above description suffices for almost all purposes in discussing the book. I won’t claim that my description is a baseline–I have no experience in the publishing business. But I’ll wager that my single paragraph would serve as a pretty good “allocated baseline” if anyone cared to produce one.

[Ulysses WikiPedia entry]:

Likewise, I don’t think that a complete copy of the source code, or a complete set of electronic drawing files, constitutes a valid baseline.

### Baselines have to measure difference ###

Consider this classic nugget of “school programming.” Back in the Cretaceous period, when Tyrannosaurs roamed the streets and I was a simple software developer, a group of us were bickering about coding style. In order to have something to chew on, one of the shell-backed veterans of our group asked a disputatious recent college graduate (a “fresh-out,” in the vernacular) to illustrate his preferred coding style by writing the C string copy routine, `strcpy()`, in that style. The idea, of course, is that since everyone already knows the content, only the style will matter. The result was this:

/* strcpy(dst, src) – make a copy of a C string. */

char * strcpy(char *dst, const char * src) {
char * dst0 = dst;
while (*src != ‘\0′) {
*dst = *src;
return dst0;

Now, the question we are discussing here is simple: is the above electronic copy of the source code a valid baseline? I have already claimed that while it meets the technical definition by being a completely detailed description of the program, it isn’t really a baseline because a copy is not the same thing as a description.

Here’s one more point in my favor: that’s not strcpy.

The C strcpy routine copies strings. A string includes the terminal ‘\0′ (ASCII: nul) character. The routine above, to the delight and dismay of my coworkers and I, doesn’t copy the final nul character. You can imagine what impact this had on the “my style is better than your style” flame-fest.

Here’s a good version of strcpy:

char *
strcpy(dst, src)
char *dst, *src;
while (*dst++ = *src++);

That’s not strcpy, either. It doesn’t fill the (useless, ANSI-imposed) requirement that strcpy returns `dst.` But it works. One reason that it works is that all C programmers know that strcpy returns `dst.` And returning `dst` is useless–it would be far better to return a pointer to the *end* of the new string. Or return `src.` But because strcpy returns a truly worthless value, nobody uses it (the return value, that is). And so the version above, elegant, concise, and wrong as it is, works. (It won’t compile, though, on an ANSI compiler: no return.)

The point, though, was that it was supposed to be strcpy. Not a broken strcpy. Not a “does what you really want, but doesn’t quite conform to spec” strcpy. **It’s called strcpy and it should do what it is supposed to do!** Again: the baseline is a description of the product. And one purpose of a baseline is to serve as a known reference for measuring differences. If we let ourselves get away with “the code is the baseline” then both versions of strcpy are valid, because there is nothing written anywhere that says the code is supposed to actually work.

Somewhere there needs to be a description. *Dee-skrip-shun.* An expression, in words, of the nature and characteristics of strcpy. And if this is the third millenium, then strcpy has a spec. Your description will say “strcpy – an implementation of the ANSI standard library routine,” and when the code doesn’t conform to the baseline? Well, that’s a *defect.* We can measure it, too, because we have a known reference to measure against.

### Baselines support work ###

I’ve already mentioned the difference between a copy and a description. Abstraction is important to that difference. A description–a baseline–should be abstract. It should allow whoever reads or hears it to comprehend the CI without having to grok the excruciating details.

Working on a project means making changes to the CIs of the project. In order to describe the changes, the designers, implementers, and testers have to share a common vocabulary for the CIs. Further, to effectively describe the changes means the shared language must be abstract: nobody communicates effectively by passing source code diffs around in email. Certainly the customers and system architects don’t communicate this way. They communicate using the language of the problem domain.

Even in an agile environment, where a customer representative is present during code development, the language of change is abstracted: “I think that button should be more obvious.” Saying something should be “more obvious” is a good, abstract, requirement for change. Implementing “more obvious” could be a matter of rearranging the layout, or changing the size, or font, or color, or shape, or surrounding spacing of the button. Certainly there’s no mention of what particular code needs to be edited to effect the change. Translating from the language of the customer representative–the application vocabulary–to the language of the CI is the responsibility of the designer. She fires up AutoCAD or Eclipse, depending on the nature of the button in question, and makes the change.

I don’t believe that the language of baselines is the same language used in change requests. In the example above, “more obvious” is not necessarily something that should fit in the baseline text. But change requests should certainly share the baseline vocabulary. When a baseline says, “The device shall present to the user a standard keyboard layout (for the base locale)” a change request should certainly be able to say “Change the keyboard so the Special Function button is more obvious.” The vocabularies aren’t identical, but they’re at the same level of abstraction.

This is work. The reason for submitting a CR is to cause work to happen. A baseline, as discussed, serves as a starting point for work. Because CRs are units of work, they must be supported by the baseline. If not, if the baseline and the CRs for the system share different levels of abstraction, the change mechanism begins to grind down. Suddenly, the baseline isn’t an effective description of the CI. So work requires translation between the language of the baseline and the language of the CRs. The extreme case is “Here’s the source code. I need you to add a feature.”

This seat-of-the-pants approach appears to work, for a time. It appears to work because everyone who has been involved with the project thinks they know where the project is, and so how to continue the effort. But seat-of-the-pants navigation has a dark reputation for good reason, and seat-of-the-pants engineering shares the same vulnerabilities. Try telling the hapless victims of the [Denver airport baggage handling system][] that they just need to make a few changes.

[Denver airport baggage handling system]:

As I said, seat-of-the-pants development can appear to work. It can, in fact, really work, if the project team stays together and if the team shares a clear common vision of where the project is coming from and what the destination is. But when the team isn’t coherent, or when the team doesn’t share a common vision, the errors begin to multiply. The various interests pulling on the project start to move it away from the straightforward course, tugging it hither and yon as different parties gain favor.

Realistically, though, when a project is doing work in this fashion the work isn’t being done based on the baselines. It’s being done despite the baselines. Because a baseline that doesn’t give everyone a common vocabulary to discuss changes isn’t really a baseline. It’s a lie. Maybe the so-called baseline doesn’t reflect the reality of the project, because the baseline documents haven’t been updated to reflect all the work that was done. Or maybe the baseline can’t be comprehended because it’s a copy, not a description, of the CIs. But a baseline is an accurate description of the CIs at a point in time. Fail any one of those tests and you’ve got a handful of mush.

3 Responses to “Defining: Baseline”

  1. Tempus Fugate Says:

    Excellent post. It’s about time some started at the beginning with this subject…

  2. Robert Cowham Says:

    In the UK there are lots of triangulation points around – little concrete blocks on the tops of hills and elsewhere.

    For more details see:

    Watching one program in the series he presented, I seem to recall that 30+ sightings were required to avoid error at any one site.

  3. Austin Hastings Says:

    Robert is right about surveys in the UK. But they were “triangulations” and apparently nobody used the term “baseline.” I think that was because baselines were only needed when allocating property that the government was going to hold and sell off. The UK, of course, qualifies as one of those ancient civilizations where every deed was describe using the “10 paces past the frog pond to the tree stump” mechanism.