 |
Aristotle's Error or Agile Smagile.
Posted by rmartin on September 02, 2003 at 08:53 PM | Comments (10)
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 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.
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.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
etreme has lost it's meaning too.
'discerning software professionals should be very wary of any new concept that bears the "agile" prefix'
The same can be said for extreme, even more so. There's a plethora of companies and products with "eXtreme" in their name. Many of them have nothing to do with the software profession. I find it odd how you talk as if you own the word. You've completely gotten it backwards. Extreme is almost as overused as "E" has been for the last 5 years (E-business, E-commerce, etc.). Now it's "X". I don't want to hurt anyone’s feelings, but "Extreme" became vogue with "Extreme sports". Applying it to software engineering is just another "me too" on the extreme bandwagon. Consider these:
"Extreme Markup Languages" conference: http://www.extrememarkup.com/extreme/, sounds like they just jumped on board, but I don't think this has anything to do with the 12 practices.
"Cooking with Java XP" (on this site)
Here XP seems to mean using Ant and unit testing. In a sense this is an example of "extreme" meaning "good". I don't think Ant or Java was necessarily intended for XP, it's just a build tool and language.
"Extreme programming: Process vs. culture"
http://www.javaworld.com/javaworld/jw-08-2003/jw-0815-xp.html
This is one of my favorites. In it the author basically takes XP to mean doing things in groups, so by forming a study group, you're doing XP. He mentions the values of communication, simplicity, feedback, and courage. All good things, but basically we're getting the picture that XP is just a synonym for "good stuff". Imagine, when a football team demonstrates courage and communication with simple yet effective plays, they're adopting XP!
It's very hard to pin down a definition or standard for exactly what XP means. It just means "good". And who can be against that? You may take issue with "Extreme Analyses" but the Extreme Sports guys probably take issue with Extreme Programming. You don't own the word agile or extreme.
Taylor Cowan
Posted by: tcowan on September 03, 2003 at 07:43 AM
-
Any support for your assertion that objects do not really model the world?
Your assertion that objects do not model the world is interesting and provocative. But I cannot see any arguments in your article supporting this assertion...how do justify this claim?
Kristen Nygaard - Speech in May, 1967, on Simula 67:
"What we want is to be given concepts so that we can handle complex problems in a manner which we are able to grasp."
I am no expert in the matter, but, to me, this quote clearly implies that he was clearly concerned with ideas beyond the low-level stack-versus-heap issue you mention.
Posted by: johanley on September 03, 2003 at 03:00 PM
-
Any support for your assertion that objects do not really model the world?
Let's turn that around. Is there any real support for the idea that objects do help you to model the real word? Is there even a decent definition of what it means to model the real world?
The support I have for my assertion comes from my own experience writing software. I find OO to be a wonderful tool for managing dependencies. On the other hand, I don't know that it helps me to model the real world, nor do I know whether modeling the real world would help me write better software.
Posted by: rmartin on September 03, 2003 at 04:27 PM
-
extreme has lost it's meaning too.
Perhaps. Though I don't find the misuse of the term Extreme Programming as pronounced or prolific as the misuse of the term Agile.
I don't claim to own any of these words. Nor do I hold out much hope that they can retain their meanings for very long. However, I note with some hope that the term "extreme programming" has, so far, held a reasonably narrow definition.
Posted by: rmartin on September 03, 2003 at 04:31 PM
-
Agile
I've read the agile manifesto and I've enjoyed some of the books by some of the authors. However, I really don't buy the agile manifesto as the long term solution to development problems. I do buy into the commitment to producing something that solves a problem, a focus that can get lost inside mis-led big-M Methodolgies.
* Individuals/interactions over process/tools.
I'm sure the blacksmiths felt the same way when their high quality manually crafted items were first threatened by lower quality mass produced items. But...tools and process improve in a realtively short time compared with humanty evolving into a more capable being.
* Responding to change over following a plan.
If you've decided you can't control change, then you've better be really good at responding to it. This works well when building something small and you can always see a way to the endpoint from where you're currently at, but building something larger requires a plan and you'd better stick with it or you'll find your "responses to change" have taken you to a path where you can't reach your goal. You can build a doghouse on the fly, you can't build a skyscraper that way.
* Working software over comprehensive documentation.
I think this speaks to a loss of focus, not a better process. The focus should always be on software that solves a problem. Avoiding documentation though is again only reasonable for small stuff where the original developers will be there they whole way through and can communicate what documentation lacks. Communicating verbally versus through documentation breaks down big time when you've got to coordinate even moderate sized groups and train new individuals. There's a reason architects draw up multiple floor plans, rather than having a "working skeleton house" and just pointing to where they envision the plumbing/piping going...
Ok, enough bashing :). Those who signed the Agile Manifesto are smart, passionate folks who've brought a great deal to our industry. But, honestly, I think the whole Agile movement is akin craftsmen saying they do things better than what can be done with the tools/processes the "terminall educated" have proposed/researched.
And that's true...right now with the tools and experiences we have, for projects of reasonably small size. I personally think you'll slowly see software development settle on successful processes and tools that help run complicated projects, with the associated incremental evolution of those tools/processes to improve them over time.
The "Agile" developer will end up like the modern blacksmith, producing good work, in small numbers, for niche customers. It might not happen in my lifetime though, so perhaps it's best for my career if I just go agile, eh?
Posted by: ckessel on September 04, 2003 at 03:29 PM
-
Agile
Mass production provides a cheaper way to manufacture lots of copies of something complicated, than a blacksmith.
Since software is easy to duplicate the main issues is how you create the first copy.
Because software tools are powerful, and becoming more so, managible projects are becoming quite small.
That is why developing software is more like a craft than a production line.
Posted by: bjsyd70 on September 10, 2003 at 02:47 PM
-
dead wrong and still useful
What is the quintessence of software?
Aristotle's 5-element model interests me. From Solid earth to Liquid water to Gaseous air to the Energy of fire to the meta-physical circular quintessence. The first 4 elements existing within the perfect, timeless and boundary-less fifth.
Uncle Bob's concern with the word Agile I share. Chris Alexander, author of another meta-concept called Patterns in “The Timeless Way of Building”, knew the danger of labels when he talked about the “quality with no name”.
I want to tap into the quintessence of software. As soon as we go meta and use a word such as Structured or Agile we return to the corrupt physical world – the sphere of fire if we are lucky. Often a rigid boundary is associated with the concept and we return to the solid earth sphere.
I do not know what the quintessence of software is. It is not just the flow of coding, more than individual creativity, the freedom that testing provides is a part of it, it is bigger than egos. Something moves, code evolves, simplicity is revealed, software works, everything changes and yet remains the same. I can feel it when it happens, I don’t know what it is, and I do know I cannot label it.
The values of the Agile Alliance can remove blocks, provide focus and allow the quintessence of software to flow. Again, I agree with Uncle Bob that the word Agile is becoming a block, a boundary (fluid but still a boundary), something to be for or against, in or out, associated with or not.
The word Extreme is from extremus: ‘being on the outside’. I think that may be why it has escaped the fate of having a boundary put around it, I hope it remains non-meta concept, an earthy test to demonstrate the quintessence of software.
Aristotle is very dead and was clearly wrong. However, his concept of quintessence may be just what we need to help us today. We can stop trying to define the next best way of building software. Whenever we go meta and use a label we build yet another boundary. We can transcend boundaries, let go of the labels and all become seekers of the quintessence of software.
Posted by: pcaswell on September 15, 2003 at 02:00 PM
-
Fabulous post
This *so* strikes a chord with me. The whole out-of-control-bandwaggonism of this industry, very succinctly summarised. Impressive stuff.
I remember all the original hoohah over "reusability" when OO went mainstream (ie C++ jobs were easier to come by than C jobs!)... I've still yet to see any truly useful reusable stuff... and I'll dare to extend that towards a sizeable proportion of the Java APIs... stratch beneath the surface and you find it's almost worthwhile writing your own from scratch - come folks, who's spent ages fighting the Swing API only to discover it's buggy/broken/not-as-reusable-as-it-says-on-the-tin??
[ducks to avoid incoming flak]
Posted by: pogo on September 16, 2003 at 06:26 AM
-
网络è¥é”€è½¯ä»¶
网络è¥é”€è½¯ä»¶
网络è¥é”€è½¯ä»¶
群å‘软件
群å‘软件
---
群å‘软件
网络è¥é”€è½¯ä»¶
论å›ç¾¤å‘软件
网站排å软件
群å‘软件
推广å°åŠ©æ‰‹ç ´è§£ç‰ˆ
论å›ç¾¤å‘软件
网站排å软件
群å‘软件
网络è¥é”€è½¯ä»¶
网站推广软件
ä¿¡æ¯ç¾¤å‘软件
论å›ç¾¤å‘软件
ä¿¡æ¯ç¾¤å‘软件
åšå®¢ç¾¤å‘软件
qq群å‘软件
邮件群å‘软件
åšå®¢ç¾¤å»ºè½¯ä»¶
ä¼ä¸šå录æœç´¢è½¯ä»¶
ä¿¡æ¯ç¾¤å‘软件
邮件群å‘软件
论å›ç¾¤å‘软件
åšå®¢ç¾¤å‘软件
网站推广软件
网络è¥é”€è½¯ä»¶
全能è¥é”€ç ´è§£ç‰ˆ
Posted by: 9uf009 on December 13, 2007 at 03:56 PM
-
wow power leveling
wow powerleveling
wow power leveling
wow gold
wow items
feelingame.com
wow tips
Most Valuable WOW Power Leveling Service
wow power leveling faq
cheap wow power leveling
wow power leveling
wow powerleveling
wow power lvl
Posted by: wowleveling3 on December 13, 2007 at 05:36 PM
|
java.net RSS Feeds
