Level 2 Ignorance

"You do not know what you do not know."

This quote travels in IT/IS communities. The humor lies in the second of the double meanings. Not only do you not know some thing. But there are also things you don't know and you are unaware of what they are. These are the Level 2 in The Five Levels Of Ignorance.

There are two dynamics at work here on the one hand your Level 2 Ignorance is like a minefield of problems. On the other hand simply learning the name of things which you do not know transforms them into Level 1 Ignorance.

These dynamics illuminate why command and control systems, everything from communism to waterfall, fail. And methods which stress grassroots bottom up development, like Agile, have shown stunning results.

The command and control tries to plan everything beforehand while all the participants are in their highest states of Level 2 Ignorance. In fact because the organization is making no attempt to discover Level 2 Ignorance it is operating at Level 3 Ignorance.

In contrast, the bottom up methods stress experimenting and thus gaining knowledge of the problem space. This will result in ignorance being discovered. Which means these methods guard against Level 3 Ignorance and thus are eliminating Level 2 Ignorance as well.

Donald Knuth Dams Waterfall

Quoting from an interview in "Communications of the ACM" 2008 08 with Donald Knuth:

The setup is Donald had written a complete spec and assigned it to bright students and then did nothing to manage them as they implemented the spec.

"To my amazement, the students, who were outstanding students, did not complete it."

Only later when he tried to implement it, did he find that it was not so easy.

"Because going from my specification, which I thought was complete, they had an impossible task..."

He later goes on to point out that even with the most complete of specifications, questions arise every 5 minutes as you write code.

In effect, his approach was waterfall with a Big Design Upfront. What he found was a cornerstone of Agile practices, you need to implement a portion of the project and then you will learn enough to start asking questions.

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.