Time was ticking down on an important project and management was breathing down engineering's neck. Engineering had been given 'one last' opportunity to decide it's fate by choosing a direction and running the ball. They chose a path and started executing it, and amazingly, things started to move quickly.

The following morning, the daily stand up was turned into a three-ring-circus of chickens and pigs from other teams to find out what the hub-ub was about. Engineering was asked for an 'overall' progress report instead of the standard round-robin 3 questions (what i did, what i am doing, what it impeding me).

After a synopsis by one of the senior engineers, marketing popped in with a comment, "How are you documenting this process?". To which, John responded almost sarcastically because he knew there was no damn time to document anything, "Our unit tests will be the documentation."

Astonishingly, another high level chicken chimed in stating, "Yes, but there should be additional explanation on the code."

One of the primary lessons of xp is that code be simple and the tests be the form of documentation for the system. Obviously, in a rapidly changing application/system there is a lot of churn on the documentation and updating said documentation can take up more time than actual programming tasks.

If everyone writes code that communicates its intent every well, occasionally sticks ///<Summary> tags on their public methods and properties where there is least likely to be change, and writes unit tests all components/projects then documentation should not be much of an issue!