Along the same lines as Web 2.0 comes eXtreme Programming. This new philosophy of how to program has 12 basic principles:
- Pair programming: two people to one screen. This is easier than it sounds. Software engineering is a very social activity, so pairing up is only natural. Pairings change naturally over time, sometimes several times a day. This practice helps introduce new people to the team, creates shared knowledge of the codebase and (most important) greatly improves the quality of the resultant code, while only minimally reducing productivity.
- On-site customer: the customer is present throughout the development process. No huge requirements documents that no one reads. This means that the customer must always be reachable to ask about a design decision. A programmer with a question should not have to wait longer than an hour for an answer.
-
Test-first development: write the tests first and then create the program until all the tests pass.
Frequent small releases: most important principle. Release a working product at some small fixed period. A beta every two weeks, for example. The customer always has something tangible to use and give feedback on. No big-bang integration. -
Simple design through user stories: simple 3x5 cards to capture requirements. These serve as a contract to further discuss the feature with the customer and find out exactly what they want.
Common code ownership: anyone on the team can change anything in the codebase (relies and builds upon test-first development and pair programming) - Refactoring: if you need to change something, do it!
- Sustainable pace: work no longer than 40 hours a week. No burn out.
- Coding standards
- Continuos integration
- Planning game
- System metaphor