Rob's Two Axioms of Setup…

1st Axiom of Setup - Setup is Governed by a Set of Rules.

The first thing most people ask when they see that axiom is, “So what are the rules?” Well, honestly, I’ve never seen anyone write them all down. I’m not even sure there is one person out there that knows them all. However, one of the personal goals I have for this blog is to capture as many rules as I know or can discover and share them with all of you. If you have rules that you know about, please feel free to comment back on my blog and I’ll be sure they get captured here.

To give you a quick example of one of the rules, “Files with a higher version should not be overwritten by files with a lower version.” The basic foundation of this rule is that files of higher version implement all of the functionality of earlier versions of a file plus new functionality. If you overwrite a newer file with an older file, programs that expect functionality that is only in the new file will be broken. Thus, the rule.

Deviation from the rules that make up this axiom basically means your life and probably your customers’ lives are going to be difficult. That leads us to our second and final axiom.

2nd Axiom of Setup - Every Rule in Setup has an Exception.

At this point most people call, “Foul! The second axiom basically negates the first axiom.” Honestly, I have to agree. However, all I can say is that reality really does works out this way. Setup is where the dreams of software design engineers (as programmers are technically called at Microsoft) meet harsh reality of user’s machines. There have been a few cases where those dreams exceed what reality can handle.

Anyway, most exceptions found in the second axiom occur because we programmers don’t have the foresight to anticipate the needs of the next version of our creations [programs]. Getting one complicated program configured is difficult. Getting the next version of that program configured on a machine that has the original version is even more difficult. It takes a truly heroic effort to plan the configuration of the next version of a program while writing configuration for the first version.

To go back to my example from the first axiom, I stated the rule that higher versions of a file implement all of the functionality of older versions. This rule is called “backwards compatibility”. In other words, the new file is backwards compatible with the old file. In reality, getting backwards compatibility right is very difficult and in some circles it is considered an impossibility (I’ll talk about the alternative “side-by-side” philosophy another day). So, there are some (very rare) cases where to get an application working you actually want to “downgrade” (install the older version of) a file so that a particular application works.

Now, the second axiom is not intended to be an excuse to ignore the rules of setup. There was a case where I was actually been called into an developer’s (as programmers are generally referred to at Microsoft) office where he wanted me to help him get this horribly whacked configuration on his machine shoved into Office setup. After I finally understood what he was trying to do I said, “Nope, no way. There is no way we can get that configuration on anyone else’s machine unless we actually ship you in the box. Want to see the world? Hope so ‘cause you’re going to be travelling to a few million desktops soon.”

He didn’t find that as nearly amusing as I did but there was no way I was going allow him to ship a complicated and fragile configuration in a product my Mom (and millions of other people’s mothers) was likely install on her machine. So he and I used the rules from the first axiom to design a simpler setup story for his feature. Fortunately we caught this early in the cycle and there was time to redesign and rewrite the feature.

So there are my Two Axioms of Setup. I’m sure we will revisit them often.