<sheepish grin>Well, my first attempt at something technical fell flat on it face.</sheepish grin>  Indranil Banerjee (see feedback) pointed out that the Mathew Wilson’s approach, which I was advocating, effectively killed the symmetry of (a.Equals(b)) == (b.Equals(a)) if one is derived from the other.  RIP, unless you can suggest a way around this that does not involve GetType().

 

I’m going to switch gears here to introduce two subjects close to my heart (for purely personal reasons, as George Tenet said).

 

The first relates to documentation.  One of my pet peeves is that our (Microsoft’s) products are not used to their full potential because we don’t do a good enough job of educating users about 'features' - features that could be useful to them if only they knew about them and how to use them.  This is, of course, not at all easy, and is one of those things differentiating experts from novices.  Experts know where to find appropriate information and they absorb it much quicker than novices do.  Thus they learn faster.

 

Software is an interesting product to provide documentation support for.  Firstly, the way that developers acquire new information and skills is very different – you don’t usually see a builder opening up a product manual while sitting on a half-framed roof, or surgeons hitting F1 in the middle of a tricky procedure.  Secondly, experts and novices use pretty much the same version of the product, notwithstanding any industrial and consumer SKU’s

 

One piece in this big puzzle is the revered FAQ.  We have one on C# at MSDN  and are always looking for appropriate questions to add to that list.  Leave your suggestions in the feedback here, or there.

 

The other subject relates to making Quality Assurance (QA) more effective and efficient.  (Now, if you think that good documentation for a wide variety of developers is an easy challenge, try this one!  The world will thank you.)

 

A phrase that one increasingly hears in testing corridors is “moving quality upstream.”  One indication of this is how we increasingly call ourselves QA instead of Test.  In the back page column of the first issue* of Software Test & Peformance – a magazine that plans to devote itself to ‘getting it right the first time' - Adam Kolawa (CEO Parasoft Corp) goes as far as to say that we really need to start over from scratch.  His basic thesis is that, instead of devoting ever-increasing resources to finding and removing errors from the product (testing-out bugs), we need to reinvent the software lifecycle to prevent errors from entering it. 

 

“This belief that testing can create quality software systems is a fundamental problem in the software industry.  We don’t think of the whole process of building and deploying software in a way that would prevent errors, because we don’t believe that it can actually be done.  Yet this error-prevention approach is not only possible but necessary.  Every mature industry has a already figured this out and stopped relying on testing as a way to make products work.  We continue to have faith that testing will deliver quality – but it never does.” 

Of course Mr Kolawa would say that, considering he has a product to sell.  But what do you think?

 

[*Issue 1 of ST&P is available as a pdf download.  If you go that far, do read the editorial too.]