CMM

1. You should plan your project.

   (Ad Hoc: We prefer nasty surprises halfway through.)

2. You should record relevant information persistently.

   (Ad Hoc: We prefer the unreliability of human memory.)

3. You should inform stakeholders of change.

   (Ad Hoc: We can’t be bothered with other people’s problems.)

4. You should monitor your process.

   (Ad Hoc: We see no need to learn from past experience.)

5. You should improve your process.

   (Ad Hoc: We are already perfect.)

1. Ad-hoc process eventually becomes a set of entrenched practices that are repeatable.
2. Eventually, they are written down so that others can learn them.
3. At some point the organisation begins to measure the way the process works.
4. And finally the organization applies those measurements to improving the process.

Extreme Programming

Process

1. User Stories
2. System Metaphor
3. Understanding (= Analysis, a bit of Design)
4. Test Case (describes Understanding, Design in mind)
5. Coding (to pass the Test Case, contraines Design)
6. Re-factoring (to make simple and cleaner code)

Rules

• Simplicity: The most simple, clean and flexible code to perform the task. No duplication. Do the simplest thing that could possibly work.
• Communication: In pairs (not stable).
• Reassesment: In the beginning of every iteration.
• No long range speculations (”You Aren’t going to need it – YAGNI.”).
• Group ownership of code.
• No role separation: No architects, Analysys, Designers,…
• Readability.
• OOD: To allow refactoring. Without it: simple change => long re-compilation.
• System Metaphor: Seed for Architecture.
• Design by Testing.
• Load factor.
• Short cycle (3 weeks).
• Worst things first
• Continuous Integration.
• Testing.
• “Clever code” is a term of abuse.
• Refactoring. “Once and Only Once.” “Don’t Repeat Yourself – DRY.”

Quotes

• There is one sure way to fail to produce a reusable framework; and that’s to design in up front. This strategy has been repeated manymany times, and the results are frequently the same: the reusable framework isn’t very reusable. [Robert C.Martin]
• The processes in use today focus on paper rather than people. Paper can’t think. paper can’t solve problems. Paper can’t adapt to change. [Robert C.Martin]
• Process is about managing fear. We put processes in place because we are afraid. If our fear is large, we put big processes in place. [Robert C.Martin]
• Working on the wrong solution early is even more wasteful than working on the right solution early and we are much more likely to be wrong than right. [Martin Fowler]
• We do have a process problem. The problem, however, is not that our processes aren’t big enough. The problem is that our processes don’t focus on the things that will improve software. [Robert C.Martin]