Evolution

Despite the title this is a techie post not a "meaning of life" post.

Brad Abrams has produced an excellent draft paper on the use of the Obsolete attribute in V2.0 of the .NET Framework.

It’s great to see that Microsoft are not allowing the constraint of backwards compatibility to stifle innovation in the CLR.

I believe the Obsolete attribute provides an opportunity for all .NET developers to improve and evolve their codebase without incurring the wrath of project managers who do not always see the benefit of design change “wish lists”. There is a strong band of “if it ain’t broke don’t fix it” advocates out there who generally don’t like to build development resource into a project plan unless it directly satisfies a customer requirement. This approach can be frustrating for architects who end up with a growing list of design changes which become increasingly difficult to introduce as incumbent APIs continue to be used in successive releases.

I had flirted with the Obsolete attribute earlier this year but since it generated a compiler error we ended up with a “big bang” exactly like the case we were trying to avoid, where the deprecated method was actually removed from the codebase.

By suppressing the warning, as Brad describes, and moving the onus of alerting to FXCop, the implementation of design improvements can be decoupled from their introduction to the main code base.

Of course there is still the possibility for developers/managers to live with the FXCop warnings or even suppress them but I have found that a change which is tested and ready to be used is much more likely to be adopted than one which is floundering on a “wouldn’t it be great if” list.

[Note: the FXCop rule, ConsiderNotUsingObsoleteFunctionality, mentioned in Brads whitepaper is not yet available in any public release of FXCop]

b.


P.S. If I was asked to recommend just one blog to any .NET developer it would be Brad Abrams