Extreme Programming

Code Early, Code Often

• Knowing how to write code doesn't tell you how to run a project
  • Where do you start?
  • What do you do next?
  • Who's responsible for what?
  • How do you tell when you're done?
• Answers to these questions define a development process
• Dozens have been formalized and described
  • But in practice, almost none are followed to the letter
  • Every real-world situation and team is different, so real process is always a variation on the theme
    • I always add extra garlic to my chili…
    • …and just about everything else, come to think of it
• This lecture looks at a process called Extreme Programming (XP)
  • Best suited to small teams that are trying to cope with constantly-changing requirements
  • Which is a good description of many scientific research teams
• Look at two alternatives in the next couple of lectures
• Remember: every team is different
  • Most important thing is not which process you use, but that you're paying attention to process
  • [DeMarco & Lister 1999] is a good introduction to teams and productivity
• Comment on this slide

Waterfalls and Spirals

• In order to understand XP, you have to understand what it's a reaction against
• Also have to understand the cost of change
  • The later a change is made, the more expensive it is to implement

  • Figure 26.1: The Cost of Change

  • Therefore important to make decisions early, and stick to them
• The waterfall model, described by Royce in 1970, describes development flowing through several phases
  • Requirements analysis
  • Design
  • Implementation
  • Testing
  • Maintenance

  • Figure 26.2: The Waterfall Model

  • Problems:
    • If different people responsible for different phases, then no one has to deal with the consequences of their mistakes
    • Whoever is responsible for testing has to make up all the lost time from the previous phases
    • Time lag: it can take a long time for changes in requirements to filter through to the finished product
• The spiral model described by Boehm in 1986 wraps this on itself
  • Get a goal from the customer, design, implement, and test it, and repeat
    • Note: Royce actually advocated doing this too, but most people have forgotten that
  • Key ideas:
    • The code teaches you about the problem
    • Customers can only find out what they actually want by playing with a working system
  • But Boehm still envisaged cycles lasting from six months to two years
    • And division of labor
• Comment on this slide

Enter the Extremists

• XP arose in the 1990s to cope with:
  • Ever-changing requirements
  • Internet time
    • Six-month iterations were longer than the lifespan of the average dot-com
• Assumption: change is cheaper than it used to be
  • Note: less data to support this than some XP advocates would have you believe…
• Basic idea: each iteration lasts only one to four weeks
  • Implies that each version is only a small step forward from the previous one
  • Benefit is constant course corrections from the customers
    • Equivalently, can re-direct project every couple of weeks to deal with changes
• Problem: how to ensure that developers stay on track when the track is constantly changing direction?
• Comment on this slide

Core Practices

• Solution is a process built around twelve core practices, which are usually grouped into four areas
• Detailed feedback
  • Test driven development: write tests before code in order to get instant feedback on correctness
  • Planning game: described below
  • Onsite customer: must be a customer representative on site to answer developers' questions at all times
    • Subsequent revisions to the process acknowledged that this is sometimes not possible
    • But frequent contact between developers and customers still essential
  • Pair programming: also described below
• Continuous process
  • Small releases, so that customers can quickly check out all of the changes and additions
  • Continuous integration: everyone builds and run tests on a very tight cycle
    • Preferably several times an hour while coding
  • Continuous refactoring: everyone cleans up what they're about to work on before they start work on it
    • And follows through into other modules if there are ripple effects
    • Ensures that code is always clean enough for the next person to start work
• Shared understanding
  • Simple design: speaks for itself
    • In practice, design of a rapidly-evolving system may seem simple to those who've watched it evolve, but not to newcomers
  • System metaphor: use simple analogies to provide a high-level overview of the system
    • E.g., it's an assembly line, a blackboard, etc.
    • Gives everyone a common language with which to discuss it
  • Collective code ownership: everyone is allowed to change any part of the system
    • No one is a bottleneck (i.e., you're never waiting on “the GUI guy”)
    • Everyone has to (potentially) eat their own cooking
  • Coding standard: essential to making collective ownership possible
• Programmer welfare
  • Sustainable pace: no one works overtime
  • Because in almost all cases, overtime actually puts the project behind
    • Tired people make more mistakes, which then have to be fixed
    • And fixing things downstream is more time-consuming than slowing down and getting them right in the first place
  • Programmer turnover delays projects as well
    • Lose all the implicit knowledge in the departing programmer's head
    • Remaining team members have to spend time bringing newcomers up to speed
• Comment on this slide

The Planning Game

• At the start of each iteration, customers write user stories to define the functionality they want added or changed
  • Each one is just a few sentences long
    • Each one should fit on a 3×5 index card
  • Describes functionality, not features
    • I.e., what the system can do, not how it does it
  • It's the developers' job to figure out what features to add to implement the desired functionality
• Set of user stories define the project requirements
  • As project evolves, throw away or update old ones as well as adding new ones
• Developers then estimate how long each user story will take to implement in ideal weeks
  • I.e., five perfect interruption-free days
• Customers and developers then decide which stories to include in this iteration, and which to leave for the next
  • If something is too big to fit into an iteration, break it down into smaller pieces
  • You're going to do this anyway when developing it…
• Comment on this slide

Pair Programming

• Pair programming is the practice of having two people work together at one computer
  • One types while the other watches and comments
  • Predates XP, but was popularized by it
• Seems like a waste of resources, but:
  • Two pairs of eyes are more likely to spot errors as they're being made than one
    • In fact, because of cognitive dissonance, the person watching is much more likely to spot errors than the one typing
  • Fewer errors translates into less time spent debugging
    • The earlier something is fixed, the cheaper the fix is
  • And pair programming helps ensure wider understanding of the system
    • More people able to work on more things
• Feels strange the first time you do it
  • And you need to reorganize desk layout to prevent back and neck problems
• But unlike many claims made in software engineering, there's empirical evidence that it actually works [Williams & Kessler 2003]
  • Though comparisons are usually made against two programmers who are both testing their own work…
  • …rather than against one programmer developing, and another testing independently
• Comment on this slide

Project Velocity

• Once the iteration is under way, the team tracks the project velocity
  • How quickly are user stories actually being implemented?
• Use this to predict how long it's going to take to finish the agreed-upon work
  • If it has taken 70 programmer-days to implement the first ten stories, it's safe to bet that it'll take 140 PD to implement the remaining twenty
  • Hoping for a miraculous improvement in productivity is always a mistake
• What to do if the team isn't going to have everything done by the deadline?
  • Asking them to work longer hours is counter-productive
  • So extend the deadline…
  • …or cut back the number of stories that are going to be implemented
    • This is why you have a customer representative on site
  • Resources, features, and schedule are not independent variables
    • You can set two, but the third then sets itself
• Comment on this slide

The Down Side

• XP and related methodologies have been criticized almost as widely as they have been adopted
  • For every bandwagon there's an equal and opposite anti-bandwagon
• Some of this is just taking pot-shots at easy targets, like:
  • “I think maybe concentration is the enemy. Seriously. If you're working on something that is so complex that you actually need to concentrate, there's too much chance that it's too hard.” (Ron Jeffries)
• But some of the criticisms are well-founded
  • If developers don't have considerable self-discipline, XP quickly degenerates into “cowboy coding”
    • Busy, rather than productive
  • Customers often need to know what they're going to get more than a few weeks in advance
    • You can't add software to a space probe three days before launch
  • Many programmers don't like to work in pairs
    • “I trust my account to do my tax return on her own; why don't you trust me to code?”
  • XP is intrinsically limited to small teams
    • Which in turn means small projects
• Comment on this slide

Summary

• Many people find that their productivity goes up when they adopt XP
• But others find that their productivity goes up when they adopt diametrically opposed processes
  • Like the one will see in the next lecture
• Option #1: most people program in the worst possible way, and anything is an improvement
• Option #2: the most important thing isn't which process you adopt, it's that you actually adopt one
  • What matters is that you're paying attention to process
  • And thinking about how to improve it
  • “The unexamined life is not worth living.” (Socrates)
• Comment on this slide