Refashioning Software

In our never ending quest to provide you with better, faster, more powerful products and tools, we some time find it necessary to redo a little of what was done before, to revamp it so-to-speak, to spruce it up, to splash on a new coat of paint and add new life to the old tried-and-true features that just seem to lack the luster of the new fangled frontiers that we foresee for the future as we scrawl upon our whiteboards and plot how the industry will be shaped by our devious, conniving, forthright innovations.

Sometimes, however, we find the glitter of new graphics insufficient or the haphazard cobbling of incremental features too stifling for the visions we hold of our grand new design.  And its at these times that we propose major shifts in the architecture, sea changes if you will, that develop into new corporate directions, coin a plethora of new acronyms and buzzwords and become overtly evangelized by the enormity of our marketing force.

Of course, not all new visions are as groundbreaking as others, and not all are as grandiose or sweeping in their changes.  Sometimes even small facets of products undergo independent upheavals that might have otherwise gone unnoticed unless you dared to look.  Surely, the designers of these pieces were motivated by the same zeal that drives the big boys to reinvent, recast and reissue their offerings.  It's easy to see how they can get caught up in it.  It's not as if our modern culture dissuades us from this practice.  In fact, we are actually encouraged by the media to remake ourselves, to remodel our lives around ever increasing fickleness in design and fashion.  As consumers we have not only come to expect it, we demand it.

Recognizing this trend in human behavior, we at Microsoft have built in the mechanisms of change into the .Net platform right from the beginning.  No longer do you have to wait for entire new platforms shifts before major improvements in subsystems and API's can be brought to you by the hard working developers here.  You've seen some of this already, those little compiler warnings when you've errantly used a feature that has been redone, remolded into its sparkly newness.  That has been our way of alerting you to the fact that the API has been revised, and that if you continue to rely on the old, outdated one, you stand a chance of being caught running code that is now inexcusably out of fashion. 

Believe me, this has provided a valuable service to multitudes of shoppers, programmers out there, as evidenced by the tremendous amount of feedback we have received since the shipment of the 1.1 version of the .Net framework.  We take this information seriously, so it should come as no surprise that we find it necessary to devise improvements to even the mechanism by which we alert you to changes.  As it turns out, many of you found the warnings of feature obsolescence unexpected and abrupt.  You felt cheated in not knowing until so late in the cycle, unable to avoid the embarrassing disclosure that your code may no longer be bleeding edge.

So we plan to introduce a new obsoleting mechanism that is more descriptive and will alert you sooner to potential changes, giving you a chance to prepare for future re-alignments that could catch you off guard. The new mechanism still comes in the form of an code attribute that you can use to decorate your own sources, but it has been renamed and moved into a new namespace.  There is a new option on the attribute allowing the specification of not only the degree of obsolescence but the time frame by which it should invariably become so.  For example, you will now be able to determine precisely how many months into the future that the current code usage will be considered in style and by what degree you will appear foolish for having used it beyond its freshness date. 

The next release of the framework will come completely redone using the new mechanism.  Each and every class will be outfitted with the new attribute, giving you the information necessary to predict when each individual feature will eventually fall out of favor.  The compilers will also change, giving you cumulative feedback on the desirability and estimated fashion sense of your software.  There will also be a tool that you can use to run against and rate precompiled modules from other vendors, so you will be able to accurately determine your softwares total degree of compliance and qualify for the new 'Microsoft Seal of Freshness'.

Of course, you will still be able to use the old obsolete, obsoleting attribute in your code, it just won't be as effective as the new design.  But don't worry, there will be a compiler warning alerting you to this fact.

But I digress

Matt

Comments

• Anonymous
  October 14, 2004
  Matt,
  
  >> Each and every class will be outfitted with the new attribute
  
  stupid me. i really thought you were already using this internally for years...
  
  WM_<G>
  thomas woelfer