Anyone can change any code anywhere is the system at any time.
Why is this a "best practice"?
- lowers our "truck-count"
- don't have to wait for Fred to make his changes to "his code"
- eliminates finger-pointing
- promotes comradery, team-building
Any disadvantages?
If this is a "best practice", then why don't people do it?
- "divide and conquer" is easier to manage?
- it's the "default"
- takes less effort
- egos?
How is it any different if done "eXtreme"?
- pairs switch often
- programmers share their knowledge willingly
What other practices support this practice?
What other practices are supported by this one?
- everyone can work on whatever needs doing, enabling SmallReleases
- helps us have a SustainablePace
- I can take vacation whenever I want
- more eyes reviewing/refactoring the code toward SimpleDesign
- more coders are knowledgable and allowed to do more Refactoring
- makes PairProgramming easier?
How do I get started?
- Once you have ownership, it's difficult to break. So, start a new project (and start it out right).
- pair program
- cross train: switch pairs often (at least once every couple days up to multiple times per day depending on the situation)
- simple design, write tests, refactor
Next: ContinuousIntegration
-- AndrewFuqua - 31 Mar 2002
