Wednesday, March 20, 2002

Back to Ed Yourdon.  When we were first starting out, he was all the rage with Structured Programming, and we read his work as if it was scripture.  However, once we started to work with his recommendations, while they weren't exactly wrong, there was definitely something missing. Fast forward to the object-oriented heyday.  With a few more miles under our belt, we again went to the then popular Yourdon-Coad reference materials.  In about fifteen minutes, we'd thrown away the book.  Way too lightweight, not practical, and examples barely scratched the surface.  But, very, very popular.  Particularly with the BigCos.  But not with the people who got the work done.  We began to see the pattern... trend-surfing anyone? 5:06:33 PM

Tripped over this presentation by Ed Yourdon: "eXtreme Project Management" and do not know what to think.  Revisiting it at a later date is probably a good idea.  These "eXtreme Project Management" folks seem to have co-opted some of the XP concepts, but seem strangely disconnected from it.  Ed Yourdon is a veteran industry warhorse who has jumped on every trend since "Structured Programming".  Does this mean that XP/Agile is now an official trend?  Hopefully that does not become the kiss of death. 4:47:31 PM

Another beef about the Agile article. Trust a construction guy to say "all these things, they're Project Management 101."  Unfortunately, building software is not the same as putting up a building.  Martin Fowler has some interesting observations regarding the differences between construction and software development in his paper "The New Methodology".   3:37:33 PM

Some background on Agile methods and XP.  We pulled this together as a starting point for explaining what Agile methods are and where they came from. 11:45:59 AM

A friend stumbled upon this watered down piece about Agile Methods, and suggested "the people interviewed do not seem to be very well informed."  Alas, this is the case.  The notion that Agile methods do not "coexist well with good architectures" is nonsense.  We have built, from scratch, and in very demanding integrative situations, many applications with great architectures using Agile methods.  Some notable objections: "He said his firm's early experiments with elements of XP on departmental applications produced code that didn't integrate well with the overall infrastructure or scale in production."  They obviously did not test early and often, or pay attention to infrastructure requirements. "We spent a lot of money fixing those scalability problems": If you need to scale and you know, before you write a stitch of functional code, write tests (or acquire automated tools) that will push the code to your scalability requirements.  Then start to write the functional code.  No functional code added will pass unless it scales. "It's just rebranding of classical project management," he said. Bits and pieces of the various agile methodologies may offer some fine-tuning, but in general, he said, "all these things, they're Project Management 101."  Agile methods turn project management 101 on its head.  Instead of assuming we can plan everything up front (we can't) we work build a process with feedback to allow us to steer.  The article statement couldn't be further from the truth. 11:42:51 AM

© Copyright 2002 Intelliware Development Inc.. Last update: 3/20/2002; 12:42:52 PM.