Skip to main content

Aristotle's Error or Agile Smagile.

Posted by rmartin on September 2, 2003 at 8:53 PM PDT

Twenty-five hundred years ago Aristotle came up with an explanation for the common observations that rocks fall and smoke rises. His idea was simple and elegant. His formulation was clever, and his arguments were convincing. He was dead wrong.

Aristotle's idea was that there were five elements: Earth, Water, Air, Fire, and Aether in that order. These four elements formed five spherical realms that made up the whole universe. The sphere of Earth was at the center. Any object made from Earth moved in a straight line towards the center of the Earth sphere unless impeded by some other force. This is why rocks fall. Water came next. Any object made from water moved in a straight line towards the water sphere. This is why rocks fall through water, but why water seems to sit on top of the earth in oceans and rivers. The third sphere was air. Any object made from air moved in a straight line towards the sphere of air. This is why bubbles rose through water, and rain fell through air. Next came the sphere of fire. Smoke rises through air because it is made of fire.

These first four elements were the corrupt earthly elements. They moved in straight lines because they were finite and corrupt. The fifth sphere was different. It was made from Aether, or Quintessence (the fifth element). Objects made from Aether moved in circles, not straight lines. The Moon, Sun, Planets, and Stars were caught within spheres of Aether that moved in perfect continuous circles. The Aether was perfect, eternal, and changeless.

Aristotle determined that the speed with which an object moved towards it's sphere was proportional to the weight of that object. Thus, a 20-pound rock would fall towards the Earth twice as fast as a 10-pound rock. This is an absurdly simple idea to test; and yet Aristotle never bothered. Having decided how things ought to work, he simply concluded that was they way they did work. In other words, he went meta. He determined a reasonable set of meta-rules for the universe and simply decided that they were true.

Going meta is the goal of any good scientist. The goal is to find the meta-rules that simplify the universe. Indeed, the fact that such meta-rules exist is one of the articles of scientific faith. However, there are disciplines to be followed. No meta-rule can stand simply on it's elegance. A meta-rule must be tested by experiment. Aristotle failed in this. He went meta, and did not test his meta-rules.

Aristotle keeps very good company, especially in software circles. Consider what happened to the ideas of Edsger Dijkstra. In the late 60's and early 70's Dijkstra came up with a set of rules for structuring software. These rules were called Structured Programming. Dijkstra's goal was to define a structure for programs that would allow those programs to be proved correct. He found that this was much easier to do if the use of goto was restricted to implementing if-then-else, while, and do-while structures.

Dijkstra was not trying to find a set of rules that make software better in terms of maintenance, or flexibility. He was trying to find a set of rules that afforded formal provability. And yet, almost immediately, the industry twisted Dijkstra's intent to mean that programs were just better when structured, regardless of whether you tried to prove them correct or not. To make matters worse, the word "Structured" got hijacked by a number of other pundits and promoters. Yourdon, Constantine, DeMarco, and their cronies, with all the best of intentions I'm sure, used the word "Structured" as a prefix to "Analysis", and "Design". The implication was obvious. Structured Analysis, Structured Design, and Structured Programming were obviously related; they became a triplet forming the "Structured Techniques". Yet nothing could be farther from the truth. Structured Programming has nothing whatever to do with Structured Analysis and Structured Design. They are completely orthogonal concepts. Structured Analysis and Design are all about functional decomposition. Structured Programming is about provability.

I'm sure that Yourdon, Constantine, DeMarco, et. al. knew this. They just took advantage of the voodoo that surrounded the word "Structured". It was the industry that went meta. the industry decided that "Structured" was "Good"; and it didn't seem to matter what the definition of "Structured" was. So long as the word "Structured" was the prefix, the suffix must be good.

This is Aristotle's error. A simple concept was extrapolated to a meta-concept; and then the meta-concept was considered to be true in the absence of evidence. Evidence was considered superfluous because the premise was reasonable. Heavy things fall faster than light things.

Something similar took place a few years later. Kristen Nygaard, Ole-Johan Dahl, and their cronies were fooling around with Algol. Algol is a block-structured language in which each function defines a block that contains variables and other functions. Those sub-functions have access to the variables define in the enclosing block. A block that contains many variables and sub-functions amounts to a data structure on the stack. Each sub-function has access to that data structure and can thereby access the variables define within the block. Nygaard, Dahl, et. al, wondered what would happen if that data structure were allocated on the heap, instead of on the stack. If it were allocated on the heap, then the variables would outlive the owning function, and the sub-functions could be called even after the owning function had returned.

If you think about this a bit you'll realize that the owning function is a constructor, the variables are instance variables, and the sub-functions are methods. Simula-67, the first object-oriented language was born.

The origination of OO was quite geeky. A bunch of geeky guys toyed around with the idea of moving a data structure, derived from a language construct, from the stack to the heap. They built a new language construct to do this. They named that language construct a "class". Where, then, did we get the idea that OO was about modeling the real world?

Somebody went meta. Somebody, probably in the early 80's, decided that OO was really about creating models of real world structures. Perhaps they were embarrassed by the geeky origins of OO. Perhaps they needed to explain OO to the masses, or bosses. Whatever it was, the geeky origins were replaced with the meta-origins of modeling the real world.

And the industry bought it. The argument is just so reasonable. Bollucks, but reasonable. Nobody wants to think that the basis for modern software development has its roots in some geeky experiment about whether data structures are allocated on the stack or the heap. We are much more comfortable with the reasonable, yet completely untested, notion that OO is about modeling the real world. Earthly objects move towards Earth, Watery objects move towards Water...

Now we are faced with yet another example. In 1999 Extreme Programming was introduced to the industry, and the industry went bananas. Half the industry decided that XP was the only way to go. The other half considered it to be an affront to all sane software engineering. The debates still rage on. However, in February of 2001, a group of us got together at Snowbird near Salt Lake City, Utah, and took the concept meta. We created the notion of Agile methods and formed the Agile Alliance.

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 Read about the Agile Alliance at And use a very skeptical eye when you see the word "agile" used.

One last point. I think it's very interesting that the word "Extreme" has escaped this fate so far. It was a close thing. It was at the 1999 OOPSLA that Extreme Programming became a buzzword. During that conference I was approached by no less than three industry gurus who asked me whether I thought there was a place for "Extreme Analysis". I take comfort in the knowledge that this term did not survive in any meaningful way. Extreme Programming still stands alone as a non-meta concept.

Related Topics >>



"Where, then, did we get the idea that OO was about modeling the real world?"

I understand the concern about genuinely useful concepts like OOP or Agile getting buzzworded into meaninglessness, but I see a couple holes in the analogy, if I may be so nitpicky.
First, Aristotle's faulty ideas were about nature: a wrong theory will stay wrong because as far as we know, the meta-rules of the universe dont' change. There can be wrong ideas about technology, but technology can and does change, so a "bollocks" idea might turn out to be a self-fulfilling prophecy. To answer that rhetorical question, OO truly did become about modeling the real world the moment we got the idea that it was about that. Unlike nature, technology is what we say it is, or at least it is always in the process of becoming what we say it is, for better or for worse. No one tested the idea that that is what OO was about for the same reason no one has or ever will "test" the idea that cell phones are for texting as well as phone calls: we decided on that.

The other thing is that origination could be understood as 1) What caused X to come into existence or 2) X's reason for being. "We have OO to model real world problems" is not factually/historically accurate for #1, but I think it's perfectly true for #2. How many geeky ideas have there been in the history of computing that did not spawn new languages and revolutionize the way programs are made? A lot.

So my point is, explaining that geeky idea to the masses was just as much a part of the origin of OO as the heap vs. stack idea, because if the argument wasn't so reasonable, OO would never have come into its own.

(Philosophy geek bonus: #1 corresponds to Aristotle's Efficient Cause and #2 is the Final Cause.

Clean code

Bob, I really liked your book. I wonder if you could write a DZone ref card on the principles you espoused in your book. I consider it my code Review Bible and encourage everyone to use it.