Extreme Programming Practice Robert Duisberg

1
Extreme Programming PracticeRobert Duisberg
2
Overview I

• What is Extreme Programming (XP)?
• Curiously Controversial
• A Set of Principles and Practices comprising
• A Software Development Methodology
• Which goes against some prevalent impulses
• And yet is remarkably productive in practice
• Why is XP?
• Devised to address a Set of Problems
• An alternative to Heavy-weight Processes

3
Overview II

• What is so Extreme about it?
• Historical Context
• The Problem(s) XP addresses
• The Principles and Practices of the
• Methodology
• Real-world Experiences and Contrasts
• with MS/development Practices
• Management Issues
• Design Issues

4
What is so Extreme about it?

• All the practices are normal and acceptedjust
  pushed.
• If short iterations are good make them really,
  really short.
• -- the Planning Game.
• If code reviews are good review code all the
  time.
• -- Pair programming.
• If testing is good everybody will test all the
  time.
• -- Integrated unit testing and acceptance
  testing.
• If design is good design is an ongoing daily
  business.
• -- Constant refactoring.
• If simplicity is good always choose the
  simplest thing.
• -- The simplest thing that could possibly
  work.
• If integration testing is important integrate
  and test
• several times a day

5
History of Computer Systems Development

• Three phases Characterized by
• Hardware Constraints
• in 1955 USAF estimated hardware gt 80 of cost
• by 1965 lt 50
• cottage industry programming
• Software Constraints
• At Garmisch 1968 Dijkstra Perlis articulate
  the Software Crisis
• Today we tend to go on for years, with
  tremendous investments to find that the system,
  which was
• not well understood to start with, does not
  work as anticipated. We build systems like the
  Wright
• Brothers built airplanesbuild the whole thing,
  push it off the cliff, let it crash, and start
  over again.
• Structured and Modular ProgrammingOOP
• User Relations/Needs
• Market Developments Ubiquitous PCs, LANs,
  End-User computing.
• Commoditization of computing intensifies
  market competition.

6
The Problem Risks

• Schedule Slips 6 months or a year, standard.
• -- Short cycles reduce the scope of slippage and
  give early warnings.
• Project Cancellations after a few slips, cut
  it.
• -- The smallest possible release is put into
  production immediately.
• Defect Rate so high the software is not used in
  practice.
• -- Testing suites ensure quality baseline
• Business misunderstood business problem not
  properly addressed.
• -- Customer is part of the team and spec is
  continually refined.
• Business changes competition and market
  climates increasingly fluid.
• -- Short releases customer involvement allows
  fluid redirection.
• False feature rich fun to program but not of
  much value to customers.
• -- Only the highest priority tasks are addressed
  in any cycle.
• Staff turnover the gurus who know the code base
  leave the project.
• -- Collective ownership of code.

7
Four Project Management Variables

• Trade-offs and interactions among
• Resources
• Inflexible too much or too little are both
  problems
• Time
• More time can improve quality increase scope.
  
• But too much can, again, hurt the project.
• Quality
• A terrible control variable. Gains are only
  short term.
• Scope
• Restricting scope can improve quality and allow
  delivery
• Sooner and cheaper.

8
Options Eliminate Downside Risk

• Project Management can be viewed as a series of
  Options
• Option to Abandon
• Option to Switch
• Option to Defer
• Option to Grow
• The Worth of these Options depend on
• The cost to Obtain the option
• The cost to Exercise the option (to Purchase the
  Prize)
• The current Value of the Prize
• The amount of Time in which you can exercise the
  option
• The Uncertainty in the eventual Value of the
  Prize
• Worth is enhanced by a strategy with
• Accurate and frequent feedback about progress
• Many opportunities to dramatically change the
  requirements
• Smaller initial investment
• The opportunity to go faster

9
Principles and Practices I

• The Planning Game
• Formalized Communication, Negotiation
  (Requirements)
• Feature/Task Specification, Estimation,
  Prioritization
• Formal use of note cards for Stories and tasks.
• Continual Testing
• Tests are written before functionality is
  implemented.
• The Test Utility is the console. Run constantly.
• Tests are never thrown away.
• Small Releases
• An extremely simple version in production
  immediately!
• Automatic build system runs the full test suite.
• Every integration (many times a day) generates a
  release.
• Two week iterations.
• The Simplest Possible Design at any moment
• Do not design for the future! (This goes against
  the grain)
• Extra complexity unused code is removed as
  soon as it is discovered.

10
Principles and Practices II

• Pair Programming
• All production code is written with two
  programmers at one machine.
• USB keyboards mice, 2 at each workstation.
  Timbuktu for remote.
• Collective Ownership
• Anyone can change any code at any time.
• Continuous Integration
• Task granularity 3 hours work gt test
  integration.
• Continual Refactoring
• Restructure system to simplify, or improve,
  without changing function.
• Constant process of design refinement.
• On-site Customer
• Available full time for questions/design.
• 40 Hour Week
• Overtime is strongly discouraged.
• Overtime two weeks in a row is prohibited.

11
The Planning Game

• The Goal
• Maximize the value of the software produced.
• The 80-20 rule.
• The Strategy
• Invest as little as possible to create the most
  valuable functionality
• as soon as possible.
• The 80-20 rule.
• The Pieces
• Story Cards and Task Cards
• The Moves
• Exploration Phase
• Write a Story set scope
• Estimate a Story set required time
• Commitment Phase
• Sort by Value and Risk
• Set Task Velocity
• Implement and Iterate

12
Four XP Values

• Communication
• Project problems invariably trace back to
  something important
• failing to be communicated.
• Simplicity
• What is the simplest thing that could possibly
  work?
• Fear of exponential cost curve leads to
  compulsively thinking ahead.
• Trust in the ability to make changes.
• Feedback
• Have you written a test for that yet?
• Dont ask me. Ask the system
• Feedback at many time scales and among various
  folks.
• Courage
• The other values in place give a programmer
• the confidence to make the changes that are
  really needed!

13
How Can this Possibly Work? I

• You cant start with only a rough plan! You
  cant constantly
• update the plan! (That would upset the
  customers!)
• Unless
• The customers did the updating of the plans
  themselves.
• Short releases so any mistake in the plan has a
  small impact.
• Your customer is sitting on the team so can
  spot opportunities.
• You cant go into production immediately! And
  you cant
• possibly make daily releases!
• Unless
• The Planning Game identified the smallest
  valuable functionality.
• You were integrating continually so costs of a
  release are nil.
• Your continual testing regimen obviates the need
  for a testing cycle.
• You make the simplest possible initial design
  subject to change.

14
How Can this Possibly Work? II

• You cant have just enough design for todays
  code!
• You would design yourself into a corner!
• Unless
• You were always refactoring and making changes
  isnt a problem.
• You were programming with a partner so you were
  confident you
• were making a simple design, not a
  stupid design.
• You cant possibly write all those tests!
• Programmers wont write tests anyway!
• Unless
• The design is as simple as can be so writing
  tests isnt that hard.
• Your coding partner wont let you get away
  without it.
• You feel good about seeing all the tests running
  (and can go home!)
• Your customer is happy when their acceptance
  tests run.

15
How Can this Possibly Work? III

• You cant refactor the system all the time!
• It would take too long and would break
  everything!
• Unless
• All the tests are run so you wont break anything
  without knowing.
• Continuous integration will alert you to
  problems at a distance.
• You are used to collective ownership, and pair
  programming
• helps to give you confidence.
• Everybody change everything everywhere all the
  time!
• Unless
• You integrate immediately so conflicts dont
  develope.
• You always write tests, so accidental breakage is
  avoided.
• You pair program, so you learn faster what you
  can well change.

16
Real-World Experiences

• Developing Products for Microsoft
• Standard Model
• 18 month development cycle 6 months late
• Redesign by Testing
• The Arrogance of the Masters of the Universe
• Burn out!
• Developing Products within Quicksilver
  Technologies
• XP Process
• Group quickly proved the most productive in the
  company!
• Extremely social. Programming is fun again!
• Personal dynamics and mutual respect are crucial
  hiring criteria.
• A sense of being in control of ones life and
  work.
• Confidence that ones work is useful (wanted) and
  not arbitrary.

17
Management Issues I

• Business Management must shift from
• Milestone scheduling
• Micromanaged design from global specs
• Specific costs for deliverables
• To
• Process oriented, incremental growth model
• Management as process facilitation
• Cash flow for accrued value.
• (But value is incremental! This is key!)
• This is pretty hard for some managers to do!
• (And yet XP can subsume the old model)

18
Management Issues II

• Power should be Split between Business
  Development.
• The results are unfortunate if either group has
  too much control.
• Business should choose
• The scope and timing of releases.
• The relative priorities of proposed features.
• Exact scope of proposed features.
• To these decisions Development Organization must
  add
• Estimates of the time required to implement
  various features.
• Estimates of the consequences of various
  technical alternatives.
• Choices (and estimates of costs) of technologies,
  processes
• infrastructures.

19
Design Issues I

• The Questions have been asked (by management)
• Where does design happen in this process?
• If programmers are only task driven, when do you
  do architecture?
• To which I answer
• Design happens all the time!
• (instead of artificially isolated at the front
  end)
• Design (like composition) is a process of
• Progressive Discovery of the possible.
• XP process gives the freedom to continually
  refine the
• Design as more is learned about the
  project/system/market.

20
Design Issues II

• In Winograds Bringing Design to Software
• Clarity of Goals
• Communication and Sharing of Goals.
• Goals change, and the Project must as well.
• Customer Focus
• Customer focus is not just an attitude.
• Requires structures support for staff/customer
  interaction.
• Designer Empowerment
• Decision-Making power
• Creativity and Engagement
• Commitment as opposed to Assignment

21
When is XP Appropriate? (or Not)

• XP works well with
• Small to medium size development teams
• (Can large teams build software at all, without
  partition?)
• Requirements are vague or rapidly changing
• (When do customers ever really know what they
  want?)
• (Where is there a market that is not rapidly
  changing?)
• XP may fail in a project culture
• that involves large teams.
• with a decision making structure that makes
  change difficult.
• with distrustful customers.
• dealing with technology that doesnt support
  graceful change,
• e.g. requiring use of large amounts of legacy
  code.
• (Government work)

22
Referenences
Kent Beck, Extreme Programming Explained,
Addison-Wesley, 2000. http//www.extremeprogrammi
ng.org/