(Sidebar: Going Meta ...)

Bob Martin actually wrote this three years ago:

As I said before, going meta is a good thing. However, going meta requires experimental evidence. Unfortunately the industry has latched on to the word "Agile" and has begun to use it as a prefix that means "good". This is very unfortunate, and discerning software professionals should be very wary of any new concept that bears the "agile" prefix. The concept has been taken meta, but there is no experimental evidence that demonstrates that "agile", by itself, is good.

The danger is clear. The word "agile" will become meaningless. It will be hijacked by loads of marketers and consultants to mean whatever they want it to mean. It will be used in company names, and product names, and project names, and any other name in order to lend credibility to that name. In the end it will mean as much as Structured, Modular, or Object.

The Agile Alliance worked very hard to create a manifesto that would have meaning. If you want to know their definition of the word "agile" then read the manifesto at www.agilemanifesto.org. Read about the Agile Alliance at www.agilealliance.org. And use a very skeptical eye when you see the word "agile" used.

It's a great article; you might want to go read the whole thing.

One thing I noticed is the agile community uses the term "Go Meta" in a very differerent way than the Weinberg community. The Agile folks mean "Take a specific practice that works in a specific context, assume it applies to everything, generalize and water it down." When used that way "Go Meta" is generally a perjorative, in that the idea is the person doesn't actually check to see if the idea applies in general. (Aristotle didn't check to see if larger objects actually feel faster; Galileo did.) Bob Martin certainly uses it that way in his article.

Then there is this other group, much more loosely collected than the Agile community. I'll call them the Weinberg community for lack of a better name, because we have been influenced by, recognize, respect, or work in the same space as Jerry Weinberg. Jerry is the author of "The Psycology of Computer Programming" as well as forty other books on software development that deal with people and systems issues.

In his books, Jerry talks about going meta in a different way: Metacognition, which is an entirely different thing. Cem Kaner has a recent blog entry that includes a description of Metacognition:

# Metacognition refers to the executive process that is involved in such tasks as:

* planning (such as choosing which procedure or cognitive strategy to adopt for a specific task)
* estimating how long it will take (or at least, deciding to estimate and figuring out what skill / procedure / slave-labor to apply to obtain that information)
* monitoring how well you are applying the procedure or strategy
* remembering a definition or realizing that you don’t remember it and rooting through Google for an adequate substitute

# Much of context-driven testing involves metacognitive questions:

* which test technique would be most useful for exposing what information that would be of what interest to who?
* what areas are most critical to test next, in the face of this information about risks, stakeholder priorities, available skills, available resources?

# Questions / issues that should get you thinking about metacognition are:

* How to think about …
* How to learn about …
* How to talk about …


In other words, when you are following process 1 because the methodology book says so, and you start to figure out "hmm ... if we keep doing 1, we'll get more of A, and what we really want is B and C, so we should probably do 2, but that will give us D, but that's okay because . .." you're performing meta-cognition, which is really higher level thinking.

My examples of metacognition are thinking about thinking, or learning how to learn better, planning how to plan better, or reasoning about reason. In that sense, I Go Meta every day, and it's a real good thing.

For purposes of my writing, when I say "Go Meta", I do not mean MetaCognition. I mean the other thing, which, ironically enough, is nearly the opposite. My concern is that Agile has gone the other thing; that we are not applying enough metacognition.

For the past year or so, I've been using the term "software metaphysics" to describe metacognition on software projects. I want more MetaCognition about software projects; I want more questioning the "why" of the process, more reasoing on the consequences and the system effects.

It's when I don't see that metacognition, when I see mindless acceptance, dogma, and folklore accepted as "software engineering", that I get concerned.

What do you think?