Obsolete's Key Role In Agile Software Development

There is one attribute that has a unique and powerful roll; Obsolete.

Here are four examples applications to the same function 'Funky'

1:
[Obsolete()]
void Funky(){...}

2:
[Obsolete("Use Freaky instead")]
void Funky(){...}

3:
[Obsolete("Use Freaky instead", false)]
void Funky(){...}

4:
[Obsolete("Use Freaky instead", true)]
void Funky(){...}

Starting with 1 you can use this attribute without any of the parameters. In this default mode it will generate a warning indicating the method is obsolete. Following the rule of "Making the Right thing Easy and the Wrong thing Hard" this should be avoided in favor of 2; Use the message string to explain what should be done instead.

Example 3 is equivalent to 2, the second parameter determines if the Obsolete attribute results in a warning (false, the default) or an error (true). It is rare that you will actually have this set to true (4) and checked in to source control, since that would break the build. But it does happen and it is a more elegant way of making "The Wrong thing Hard" than commenting out the obsolete code.

How you will use 4 is to explore the level of effort involved in changing code. In a typical "Drain A Swamp" effort; the code might not even compile from source control without error. After considerable effort you will get the errors out but be left with numerous warnings. This morass of warnings will hide the ones generated by Obsolete. So working with generate error set to true will provide a count of what is left and a road map of what to fix.

In Green Field efforts Obsolete provides a effective means of communication of intent between teams working on separate modules. It raises the flag that one team wants to change something but does not force another team to change immediately. Perhaps the second team needs to transform and obsolete some code as a result. On balance it allows for teams of programmers to behave in an agile manner.

But perhaps the best benefit of Obsolete is the knowledge that it is there and provides a way for a programmer to take back his mistakes. What is not stressed enough about Agile methodologies is that it is a safe way for programmers to make mistakes. This frees them to discover things that can never be known beforehand in a Command and Control Central Planning mode of development. By fearless experimentation and ruthless obsoleting programmers will flow past problems, discovering the easy way much like water finds the downward path to the sea.