The Pragmatic Programmer - Chapter 8: Before The Project

The Requirements Pit

• No one knows exactly what they want.
• Our job is to help people understand what they want.
• Requirements are learned in a feedback loop.
• Prefer short iterations: one that end with direct client feedback. This keep us on track, and makes sure that if we do go in the wrong direction, the amount of time lost is minimized.
• Work with a user to think like a user.
• Policy is metadata.
• The best requirements documentation is working code.
• Requirements documents are not for clients. They are for planning.
• Use a project glossary.

Solving Impossible Puzzles

• The secret to solving a puzzle is to identify the real (not imagined) constraints, and find a solution therein.
• Identify the most restrictive constraints first, and fit the remaining constraints within them.
• When it comes to observation, fortune favors the prepared mind.

Working Together

• Conway’s Law: The social structures and communication pathways of the team and the organization will be mirrored in the application.
• Development teams that include users will produce software that clearly reflects that involvement.

The Essence of Agility

• Agility is not a noun; Agile is how you do things.
• Manifesto Agile:
  1. Individuals and interactions over processes and tools.
  2. Working software over comprehensive documentation.
  3. Customer collaboration over contract negotiation.
  4. Responding to change over following a plan.
• Recipe for working in a agile way:
  1. Work out where you are.
  2. Make the smallest meaningful step towards where you want to be.
  3. Evaluate where you end up, and fix anything you broke.
• A team that doesn’t continuosly experiment with their process is not an agile team.