Thoughts on Wikipedia info on 'Agile software development'

   First of all, the claims of what Agile is are just plain appealing on the surface.  The article begins by saying that Agile "encourages rapid and flexible response to change" and "promotes foreseen tight interactions throughout the development cycle".  Sounds good, right?  It is often stated (sometimes without evidence, as some kind of anecdote) that many software projects are never fully completed because by the time they are some ways along in construction, one of two basic things happens.  Either the project falls out of scope with what the customer originally wanted (drifted, in a sense), or the product has become unnecessary or unfeasible in some way (too expensive, obsolete, whatever).  It would appear that one of the stated methodologies of Agile is aimed at addressing this issue (to the extent that it exists) by promoting close interaction between developers, managers, and the client.

     I'll say it was surprising to learn that the famed "Agile Manifesto" is so short.  The actual content of it is a mere 68 words.  However, you can see responses to some of the known issues with software development I just mentioned.  For instance, the Manifesto says it values "responding to change over following a plan".  To me, this means that Agile is expressly concerned with the pitfall of blindly 'completing' a project as planned despite changing conditions being present.  In a similar sense, the other three statements of value indicate a belief that interactions are more valuable than documents and working software is better than descriptions of it.  This all seems to make basic sense, given some canonical miscommunications between clients and the developers they contract with.

     Another interesting note in this article is the idea of a continuum of software development methods between ones that are 'adaptive' or 'predictive'.  Agile is stated to be an adaptive method, in that it allows for changing requirements and can be quite uncertain about the future tasks and problems the current project will present.  This is in contrast to a predictive method, which generally attempts to map out or 'predict' the issues and milestones of a project in advance and not change them unless absolutely necessary.  The notion of a predictive method almost seems flawed to me, as it is rigid in a way that does not allow it to actually do useful things unless it can know exactly what they will be far in advance.