From ThoughtfulReactionsToXp

	* TravelLight (No Non-Code Documentation)

I'm aware of no XP project that is completely without documentation. The XP baseline, however, is that there are no standard XP documents. Well, wait, there are the story cards, with value and risk and estimate associated. Oh, and there are the unit and functional tests. Oh, and the associated graphs. Oh, and the standard status reports addressing the FourVariables. Oh, and the code. But basically, there are no standard documents. We require that every additional document be assumed guilty until proven innocent.

		* Design documents are very helpful for conceiving and explaining complex pieces.

Design documents are one way to conceive and explain things. The number of phone calls and meetings used to "clarify" documents suggests that documents aren't exactly great. InTheRealWorld people seem to use the documents as an occasion to talk and find out what is really going on.

In a room full of peers something faster and lighter is better. That's why rooms full of peers don't work in Rose or send memos to each other, they write on whiteboards, draw on bar napkins, move CRC cards around, talk. 

If the conceiving and explaining have to take place over extended space (and perhaps over extended time, but that's another topic), documents may be necessary. When conceiving and explaining can take place quickly and in one room, documents are much less necessary.

		* Visual models (UML) are a superior way of communicating non-trivial designs.

Communication is the key, we agree. As a visual person, I personally like diagrams. (rj) However, I have learned that the motion and touching of the cards in CRC is even more highly communicative than a visual model.

I am also visual, I also like diagrams. One problem with visual model diagrams is that the system evolves past them as it develops and the model diagrams either become meaningless or the project must spend manpower to keep them updated. Since the diagrams are not going to contribute to the functionality of the system, XP, as a minimalist approach, would just leave them out altogether. -- DonaldMcLean

		* How are non-coders (managers, analysts, testers) supposed to understand the system, by reading code?

XP does not identify an analyst role separate from developers. Customers specify requirements in the UserStory, the primary XP document. Developers determine how to implement the story. I'm not sure what other functions of analysis might be missing. Please inquire further.

Testers are full-time members of the team. It could be argued that testers should not understand the system (i.e. Black Box Testing). They understand the ''requirements'' by reading the stories. They understand their test-making tools. If they write code to implement tests (C3's testers did this at the beginning), they will in fact know how to code.

Most of the role of tester is accepted by the programmers applying CodeUnitTestFirst. If you've never done this, it is likely to dramatically reduce the incidence of defects in code. If the code is solid enough, you don't need an additional layer to identify the ''little stuff.''

There is little reason to imagine that managers are born understanding UML. We find that they readily understand a presentation of the design using CRC cards. If managers did need a paper form to help them understand the system, a few high-level diagrams would probably suffice.

Contributors: RonJeffries, DonaldMcLean

----

''Unrelated to the above, but I can't think of an alternative term:''

I've heard/used the term TravelLight as the opposite of CompulsiveCustomizer.  The idea is that one should not be too dependent upon a particular set of tools, techniques, or configuration parameters to be able to get one's job done.

I've had jobs where I used several different development machines, using several different operating systems, in the course of each day.  I've had jobs where I received a new development machine every week or two, requiring installation of everything I needed.  I've been in a situation where the development environment stopped working every few days, requiring a full re-install every time.  I've been working on multiple projects, each of which used a different methodology and different set of coding standards.

From these experiences, I've developed the habit of minimizing customization and dependencies upon installed software.  Some of the things I do are:
	* Use default settings for all applications as much as I can stand.  Re-customizing every machine gets tedious, so I just try to get used to default window layouts, colors, default editor settings, etc.
	* Put configuration files, scripts, and favorite utilities in VersionControl system.  Then, when I get a new machine, I can just retrieve all my customizations from the repository.  And when I make a change, it is easy to migrate the new version to all the other machines.
	* Stick with "standard" software.  Windows, Microsoft Office, and Visual Studio may not be the best software packages in the world, but they are ubiquitous.  They are likely to already be installed on whatever machine I get stuck with, and if they are not, nobody will argue if I want to install them.  Also be willing to accept whatever versions of the "standard" packages are in use.
	* Use free software whenever possible.  This eliminates the cost and hassle of buying new licenses for every machine I use.  (Where this rule and the previous rule conflict, I go with the minimal-hassle option.)
	* Be knowledgeable about non-preferred software.  I can use vi, I can use emacs, and I can use Visual Studio's editor.  I can use bash, I can use csh, and I can use ksh.  I can write scripts using Perl, TCL, bash, or .bat.
	* Use web-based e-mail.  This lets me do e-mail from any machine with Internet access.  I use other web-based services when convenient (for example, a personal wiki for keeping project notes).

--KrisJohnson

See also InfrastructureInXp