While working with a client in the U.S. state of Rhode Island, I discovered an interesting approach to providing directions: don't give directions by using landmarks that still exist, but rely on someone's historical knowledge of what landmarks used to exist. Directions in Rhode Island, as a result, sound something like this: "Oh you need to find the airport? Just travel down Kilvert and turn left where the old AlMacs used to be." This line of thinking is so pervasive, that's it difficult for a "foreigner" to actually figure out how to get anywhere. However, most locals, who've been around while, tend to instantly understand -- and can more fully comprehend the directions, as well as the geo-context.

As an analyst and a technologist that's been working with SharePoint technologies since before the official release of SharePoint 2001, I too am guilty of using these historical references. In fact, I find them almost invaluable in understanding how to solve problems or understand why certain functions in SharePoint operate the way they do.

In many cases, Microsoft builds on previous approaches to construct improved functions -- sometimes to the detriment and sometimes to the benefit of the end user. For example, when Microsoft integrated "the old Content Management Server (MCMS)" functionality into SharePoint, the result wasn't quite like MCMS and not quite like SharePoint (although certainly more SharePoint than MCMS). What Microsoft actually did was to inject basic MCMS concepts into the existing SharePoint architecture (e.g., created a "pages" library in SharePoint to explicitly hold HTML pages) and extend implicit SharePoint concepts with MCMS-like flexibility (introduced field types and controls that existed before, but weren't explicitly extendable).

This approach yields statements like: "How do you write a custom SharePoint field control? It's like writing and old MCMS placeholder."

In our SharePoint Report 2008, we use this instruction-through-historical-context to improve overall understanding of the current product. While we don't spend a lot of time reviewing history, the report provides some valuable historical context for SharePoint's approach. As we point out, this is sometimes to the detriment of SharePoint (trying to fit all MCMS constructs inside the existing SharePoint architecture), but it does occasionally work to its benefit -- for example, with the list construct.

As I continue to travel back and forth to Rhode Island, I always have to smile when I hear statements like "you're sitting in the PMO's old office." However, I believe I've gained an appreciation for the context that accompanies the language