Extreme Programming Notes

This is an outline for a talk I gave in 2002.

  1. Executive Summary:

    Major Premise of Extreme Programming (XP): changes to design and implementation are no longer as costly as in the past due to Object Oriented technologies and the ability to automatically test systems.

    This leads to two corollaries:

    1. Systems should be coded in a series of quick iterations with the early iterations having the most business value so they can be used immediately by the customer.
    2. We should only design and code those portions of the system needed for the current iteration.
    3. The above two corollaries will only work if you also have automated and continuous testing.
  2. Recommended reading:

    Extreme Programming Explained, Embrace Change by Kent Beck details this programming paradigm.

    Click to Buy: Extreme Programming Explained
    According to the author XP is "a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software."

  3. Background
    1. The Problem
    2. "The basic problem of software development is risk"
  4. XP Assumptions
    1. Cost of Changes are lower now

      Kent states that with the advent of new technologies like Object Oriented Design, and automated testing, faster machines, the cost of change later in a system is not as high as it use to be.

      In school we learned that the cost of fixing a mistake goes up by a exponentially for each phase where it is missed (e.g., its much more expensive to add a feature in the coding phase than the design phase). We therefore spend most of our time up front trying to catch requirement errors.


      Traditional Relative cost of defect or missing feature by phase

      Phase Relative Cost
      Requirements 4
      Planning 8
      Design 16
      Implement 32
      Test 64
      Operation 128

      Kent believes we should think of the curve as more linear and act accordingly.

      Phase Relative Cost
      Requirements 4
      Planning 8
      Design 16
      Implement 22
      Test 24
      Operation 26
      If this is true, what are the implications in view of the risks seen earlier?
      1. We can design less up front and start prototyping/coding earlier
      2. Design should only include the features needed in this iteration
      3. Don't add hooks for features not yet implemented
      4. Don't be afraid to continually change the design and code as needed
    2. We never really were all that good at designing the entire system at the beginning anyway
    3. Change

      Life changes, requirements change, our experience and expertise change

  5. Extreme Programming
    1. Key Aspects of XP
      1. The big problems are uncertainty and risk
      2. Testing is done continually using automated scripts
      3. Coding is the key activity
      4. Programming is done in pairs
      5. Write the most business critical sections first
      6. Develop code in short complete iterations
      7. Communicate through talking, testing, and source code (not through massive documents).
    2. Economic Analysis ("The Time Value of Money") and Risks

      The programmer needs to continually calculate the value of his time.

      Will this new feature add immediate benefit to the client? If not, how much more difficult will it be to add it later? What is the most valuable task I can do right now? What is the ROI (Return On Investment) of task "A" verses task "B"?

      The programmer also needs to think of the risks of the project being canceled without getting any benefit from the project. It is better to deliver something quick and simple that solves an immediate business problem, than to build a system that solves all the problems, but has the risk of being canceled in the future.

      What is the risk that a feature will not be needed in the future?
      What is the risk that we will develop technology to do it better than we plan right now?
      What is the risk of being able to buy it in 6 months?

    3. Four Values
      1. Communication
      2. Simplicity

        "XP is making a bet. It is betting that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do more complication thing today that may never be used anyway."

      3. Feedback
      4. Courage

        Take charge! Don't be afraid to change things that need to be radically changed.

    4. Basic Principles
      1. Rapid Feedback
      2. A customer representative lives with the developers.
      3. Assume Simplicity

        Use the simplest possible solution. Don't plan for future features, don't plan for reuse. Change the software in the future when you need to. Think "Return On Investment" (ROI)

      4. Incremental Change
      5. Embracing Change
      6. Quality Work

      7. Don't sacrifice quality, it takes less time in the long run to do it right the first time. Do less, but do it better.

    5. Minor Principles
      1. Travel Light
      2. Documents should be Few, Simple, and Valuable
    6. The Basics
      1. Coding
        1. Paired programming
        2. Communal ownership of code
        3. Use coding standards
        4. Optimize last
        5. Forty hour work weeks in the US, 37.5 in the UK
        6. Integrate often
      2. Testing

        Unit testing is done frequently

        "Programming when you have the tests is more fun than programming when you don't."

        Functional tests are based on customer Stories. The results of the tests are verified by the customers.

      3. Listening to the Customers
      4. Design

        Good design results in modules that are independent, flexible, and extensible

    7. Management Responsibilities
      1. Metrics
      2. Gather only a few meaningful metrics and display prominently on a big chart
      3. Coaching
      4. Tracking
      5. Intervention
    8. Facilities

      The office layout should support paired programming and maximum communication, while retaining some space for private phone calls. The ideal space is an open room with the fastest machines in the center on communal tables with space for two programmers. Along the walls are personal cubes for phone calls.

    9. Business/Technical Balance

      Power in a project should be divided between the Business people and the technical people. If it gets out of balance either way problems develop. If the business drives too much, a project can be loaded with too many technically risky items that provide little real value. If the techies are in charge the project gets too full of technically interesting items that have little business value.

      Business people should decide the scope or timing of the releases, the needed features, and the priority of those features.

      Technical people should give good estimates for the time and cost to implement features.

    10. Planning
      1. Only plan for your next horizon
      2. Ignore dependencies between parts
      3. Goal

        Build software with maximum value

      4. Strategy

        Implement the most valuable business processes first

      5. Three phases of a project
        1. Exploration

          Make story cards for each major activity (similar, but different than Use Cases) and estimate the time to develop

        2. Commitment

          Business people sort the stories by priority; Developers sort by risk; Business then picks a set of stories to implement

        3. Steer

          During development, trade-off need to happen as development (and business) learn more about the project. Stories may need to be traded/removed, or the dates moved

    11. Design
      1. Have the simplest design that works for the current test suite
      2. We are betting that requirements change frequently and that if we design the whole system at the beginning we will waste time, because some of those items will never be used. Also some of the items we will learn to design better after a little experience.
      3. Small initial investment
      4. Rapid feedback
      5. Embrace change and travel light
    12. Testing
      1. Testing should be done frequently (daily) and automatically
      2. Tests should be easy to write and to get results (e.g., JUnit for java)
      3. Design tests for those parts more likely to break
      4. Only write code, after you write the test for it and it fails
  6. When not to try XP
    1. Really large teams of programmers (greater than a dozen?)
    2. Testing is too complicated
    3. Hardware is too expensive
    4. The Design has to be right the first time (Database schema used by outsiders)
    5. When the office physical layout doesn't support paired programming
  7. Miscellaneous Notes:
    1. Embrace change - don't grimace when requirements or design changes, ask "What took you so long?". Design your process to handle it joyfully
    2. Write the test case first, and then the code.
    3. After unit testing, do integration testing immediately.
    4. Use XP when the requirements are vague or changing
    5. Key premise: the cost of change is not as high as it used to be
    6. Be sure to test rigorously and often with automated scripts
    7. Its important to have snacks and toys around
    8. Have a morning "stand up" meeting daily
    9. "Make it run, make it right, make it fast"?
    10. Have an integration machine for testing
    11. You can implement XP in parts, but won't get near the benefit
    12. Delete any functionality no longer needed
    13. Only make a solution for today's problem
    14. Instead of "If it ain't broke, don't fix it", we improve code when we need it to be better
  8. Some resources
    1. www.pragmaticprogrammer.com/
    2. https://www.xprogramming.com/ - an overview
    3. https://www.extremeprogramming.org/ and it's rules
    4. Test-driven programming