The principles of extreme programming

Working in pairs. Whenever you're writing or changing project code, there should be two of you at the computer. The one who is holding the keyboard and mouse should be focussing on the details of the immediate section of code that she is writing. The other one should be considering the code at a higher level -- questioning whether the approach will work and whether it will integrate successfully with other code, thinking up test cases, looking for opportunities to refactor, and catching mistakes.

Collective ownership. No one programmer owns any of the project files. Anyone who sees an opportunity to improve the project code in any way can, and should, make the improvement in the code file right away.

Simple design. The goal is to write the simplest, most direct program that meets the specification and passes the tests, without duplicating any code. At any given point, the program should meet its specification completely without doing anything outside the specification.

Immediate, automatic testing. Whenever a bit of code implements a non-trivial programming decision or performs some action that might happen in more than one way, you should supply tests to make sure that that bit of code is correct. Write the test before the code; run it to make sure that the test fails; write the code; run the test again to make sure it succeeds. Develop and extend the tests as you develop and extend the code.

Refactoring. When you're about to add a feature to some project code, ask whether it is possible to change the code so as to make it easier to add the feature. When you have added a feature, ask whether it is possible to simplify the program while continuing to pass all of the tests.

Continuous integration. Once a day, if not oftener, compile the entire project and run all the tests for all of its parts, fixing things until it all works.

Frequent, small releases. Release a new version of the project every time there is a significant improvement in its functionality.

Coding standards. Agree on a common programming style and follow it strictly.

On-site feedback. Whenever a question arises about the scope, purpose, or general composition of the project, about what users of the program would want it to do or should see as it runs, or about the specifications or the controlling metaphor for the project, ask me about it -- don't guess.

Having a controlling metaphor. For each project, there should be an overall metaphor that guides the work and provides the framework within which non-technical users will understand it. This does not have to be anything sophisticated, but it should be clear enough to provide a basis for some design choises.

Planning by negotiation. Begin each project, and each new release of an existing project, with a negotiation between the representatives of the users, who will specify the nature and purpose of the project and set priorities and release dates, and the implementers, who will estimate how long it will take to implement various features, work out the scheduling details, and explain the technical consequences of design alternatives.

Out at five. Ideally, the working day ends at five o'clock, the working week on Friday. Exceptions can be made in order to get the project to compile successfully and pass tests, but the goal is to pace yourselves, not to go all out on every problem.