The Other Stuff

This is where the bulk of the refactoring takes place. Here we make some changes to XP s practices, tenets, and general recommendations. Plus we mix in a few practices of our own:

• Interaction design: Hire an interaction designer to get the usability aspects of the software right before it s written, and revisit usability incrementally throughout the project.

• Planning game: Plan in detail for the next iteration and in less detail (milestones) further into the future.

• Short iterations: Use fixed 1-month iterations, but track progress on a weekly basis.

• Small releases: Release early and often to the customer, but beware of putting the project into maintenance mode too early.

• Metaphor: Complement domain models, architecture, and design with a unifying metaphor.

• Simple design: Always keep it simple, but don t turn a blind eye toward what you know you ll need to add soon.

• Refactoring: Refactor when necessary, but not as a replacement for up-front design.

• Testing: Automated tests are good, but try not to rely too heavily on them repeatedly saving the day.

• Programmers write their own tests: This gets programmers thinking about code quality.

• Quality assurance: A separate QA team is a vital component of software development.

• Collective ownership or individual ownership?: Leave this to your team to decide.

• Requirements documentation: Define the requirements in detail, but break into subprojects .

• Design documentation: The documentation should be virtually a by-product of the design process.

• Colocated team: This is a nice-to-have , but don t count on it always being possible.

• On-site customer: The colocated customer isn t a replacement for a detailed requirements spec. Specifications save projects!

• Pair programming: Program in pairs for difficult tasks , but don t force people to pair up!

• Programmers do design: Whoever designs the software should also be involved in its implementation.

• Spikes: Use occasional spikes (small ad-hoc prototypes ) if necessary.

• Continuous integration: Integrate and fully unit-test the entire system at least once a day.

• Sustainable pace: Work at a sustainable pace, but do be prepared to work some extra hours every now and again.

• Collaborative coding standards: Get the programmers involved in defining their own coding standards, and then make sure they stick to them.