This is a perfectly valid strategy in many areas, but it isn't always fully extreme.

My favorite example from the recent past is from DougLea's very helpful ''Concurrent Programming in Java'' Second Edition, published September 1999, only a matter of weeks after the much previewed EmbracingChange.

----

In Section 1.3.5, ''Further Readings'':

Technical issues are only one aspect of concurrent software development, which also entails testing, organisation, management, human factors, maintenance, tools and engineering discipline.  For an introduction to basic engineering methods that can be applied to both everyday programming and larger efforts, see:

Humphrey, Watts. ''A Discipline for Software Engineering'', Addison-Wesley, 1995.

For a completely different perspective, see:

Beck, Kent.  ''Extreme Programming Explained: Embrace Change'', Addison-Wesley 1999.

----

When I read that, I knew that Kent and the others had done it.  Broken the mold.  Well done!

--RichardDrake