Extreme Programming

Kent Beck, Daedalos Consulting

Topics

• Confidence - How does the team achieve and maintain confidence in the program?

• Communication - How does the team learn and remember?

• Design - How does the team maintain the life of the project?

• Coordination - How does the team make the best possible strategic decisions?

Topics

Testing

Communication

Organic Design

Planning

Today’s Purpose

• To enable you to adopt XP practices

• Goals to keystrokes - concrete things you can do

• Clarify, not debate

Topic Structure

• Philosophy - the general approach of XP to the topic

• Example - a demonstration of the practices

• Practices - 10 extreme things you can do

• First steps - what you should try first

Confidence Philosophy

• Tests are tangible confidence

• No program feature is done until it has an automated test

• Responsibility for testing is split between developers and testers

• Tests are run often

Confidence Example:Developing with Tests

1. Think of a feature

2. Write a test

3. Implement the feature

4. Run all the tests

Confidence Practices

• Fixture

• Assertion

• Alternative Logic

• Unit Test

• Functional Test

• Other tests…

Good tests

• Automated- comes back with a single answer

• Predictable- always produce the same result

• Isolated- failure in one test does not affect others

• Cheap- easy to write

• Stable- cheap to maintain

Fixture

• Predictable basis for testing

• Freshly allocated for every test

• Fixture used by a single test is initialized in the test method and stored in local variables

• Fixture used by more than one test method is initialized in setUp() and stored in instance variables

Assertion

• Call assert(aBoolean) to express expected value of an expression

• Call assertEquals(a,b) to express that two objects should be equal– Also works with long and double (add others if

you need them)

Alternative Logic

• Who watches the watchers?

• Get expected results from another computed source– Excel– Calculator– Published material– Existing system

Unit Test

• Written with a particular piece of logic in mind

• Best written before coding

• Responsibility of the developer

• All unit tests must run at 100% after every integration (several times daily)

• Ideally should catch all errors– Functional failures become unit tests

Functional Test

• Written with a particular story in mind

• Best written before coding (but be realistic)

• Expressed in customer-oriented notation

• When all the functional tests run, the customer should be confident about shipping the system

Other Tests

• Acceptance test- measurement of the fitness of the system for deployment

• Performance test- assertions about the resource usage of a test, not just its answers

• Stress test-simulation of the worst expected operating conditions

Tests in Practice

• Always keep the unit tests at 100%- if they aren’t, you don’t have anything more important to do than fix them

• Test answers, not implementation artifacts

• Graph functional test performance

01020304050607080

Week 1 Week 2 Week 3 Week 4

WrittenRunning

Confidence First Steps

• Write a unit test for existing code

• Write a unit test before implementing

• Run your test suite after integrating

• Ask your customer for functional test data

• Run two developers’ tests together

Communication Philosophy

• Face-to-face communication is best

• Exploit the source code as a medium

• Only produce valuable documents

Communication Example

• Pair programming extensions to Money

Communication Practices

• Pair Programming

• Composed Method

• Simple Superclass/Qualified Subclass

• Role-based Variable Names

• Intention Revealing Method

• Double Dispatch

• Unit Test

Pair Programming

• Work two developers to a machine

• Write a test

• One thing at a time– Keep a to-do list of issues to be addressed in

the future

• Shift the keyboard when the other partner sees something wrong

Pair Programming: Architecture

• Work side by side

Not ThisOr ThisThis

Composed Method

• How big should a method be?

• Issues– Following the flow of control– Performance– Communicating “what” and “how”– Overriding

• Do one thing per method– Few lines– Consistent level of abstraction

Intention Revealing Method

• How do you name methods?

• Issues– Length– Parameters– Intention– Implementation

• Name methods after what they accomplish

Simple Superclass

• How do you name the root of a hierarchy?• Issues

– Long names are hard to read and format– Short names don’t communicate enough

• Use simple one word or two word names– Figure– Account

• In German, it is okay to use abbreviations

Qualified Subclass

• How do you name a subclass?• Issues

– Communicate about the superclass– Communicate the difference

• Prepend an adjective to the superclass you want to declare allegiance to– RectangleFigure– TradingAccount

Role-based Variable Names

• How do you name variables?• Issues

– Type– Role– Scope

• Name variables after the role they play in the computation– subject

Unit Test

• How do you communicate how an interface should work?

• Issues– Clear– Short– Easy to write

• Explain the interface with a unit test

Formatting

• How do you format code?

• Issues– Vertical space– Horizontal space– Block structure

• Adopt a common style

• Learn to read and write several styles

Literate Program

• Tell a story that includes each class and method in your program

• Between blocks of code, insert text and pictures that tie code fragments together– “Remember we said we would need

addMoney()?”– “With these pieces in place we can now

implement addMoney()”

Communication First Steps

• Pair program for two hours on a defined problem

• Rewrite code using the practices before fixing it

• Write a literate program

Design Philosophy

• Small initial investment

• Immediate feedback

• Continuous evolution

• Universal contribution

Design Example

• The JTest Framework

• Provides lots of leverage per line

• “Pattern dense”- you can see many patterns at work in a small number of classes

• Easy to extend

TestCase- Command

• It would be simpler to just send messages

• We need to queue up tests to be run later, so we can run them together

TestCase

Initialization- Template Method

• Different TestCase subclasses need different initialization

TestCaserun()setUp()tearDown()runTest()

setUp();runTest();tearDown();

Different Test Cases- Pluggable Selector

• Different TestCase instances need to execute different methods

TestCasefName runTest()

Method runMethod= null;runMethod= getClass().getMethod(fName, new Class[0]);runMethod.invoke(this, new Class[0]);

TestResult- Collecting Parameter

• Separately record results of test running

• Lightweight way to save history

TestCaserun(TestResult result)

setUp();try {

runTest();}catch (Throwable e) {

result.addError(this);}finally {

tearDown();}

Test- Interface

• Separate external specification of TestCase from implementation

• Allows for different implementations

TestCaserun(TestResult result)

Testrun(TestResult result)

Testrun(TestResult result)

TestSuite- Composite

• Run many tests at once

• Aggregate at higher and higher levels

TestCaserun(TestResult result)

Testrun(TestResult result)

Testrun(TestResult result)

TestSuiterun(TestResult result)fTests

Summary

Command TemplateMethod

PluggableSelector

CollectingParameter

Interface Composite

Design Practices

• Greenfield design

• Refactoring

System Metaphor

• How do you coordinate the design decisions of many designers?

• Centralized, detailed design offers control, but gives upinclusion and feedback

• Decentralized, piecemeal design can go out of control

• Choose a single metaphor for the system. Derive vocabulary and basic design from the metaphor.

CRC Cards

• How do you design when you don’t know what to type?

• Abstract design notations let you move fast, but accumulate risk

• Concrete design requires many detailed decisions

• Hold a 20 minute carding session. Include the responsible developer, other interested designers, and a customer.

CRC Card Examples

Money• perform arithmetic• convert to other

currencies

MoneyBag• perform arithmetic• convert to other

currencies

ExchangeRate• convert Money

from one currency to another

CurrencyExchange• convert Money to

specified currency

Spike Solution

• How do you design when you have too many questions to answer?

• You want to solve them all

• You can’t solve them all at once

• Build a system that operates end-to-end, but only for one test case

Refactoring

• Always work a little at a time

• Test between refactorings

• Don’t do anything dangerous– Tomorrow it may not be dangerous

Extract Method

• Find a piece of a method that can be explained standing alone

Move Method

• Find a method that sends two or more messages to another object

Conditional -> Polymorphism

• Find repeated conditional code

Display() Visible: Invisible: Disabled:

Contains() Visible: Invisible: Disabled:

Visible DisabledInvisible

Visible DisabledInvisible

Static:

Dynamic:

Extract Component

• Find a subset of instance variables that only make sense with each other

...amountcurrency...

...money...

amountcurrency

Extract Component Steps1. Create class with extracted instance vars

2. Add instance variable to original classInitialize to an instance of the extracted class

3. Every setter of the original instance variables also sends setting message

4. Every access to original instance variables send getting message instead

5. Remove original instance variables

6. Move methods

Design First Steps

• Reach a design decision, then code for an hour each way

• Use patterns to describe your system

• Set a direction, then refactor towards it

Coordination Philosophy

• Business people make business decisions, technical people make technical decisions

• A little planning for setting priorities, more when the team needs details to implement

• Be prepared to refine and change the plan during development

• Clear rules• Frequent feedback

Coordination Example

• Play act– Story writing– Estimation– Planning– Iteration planning– Development– Recovery– New story

Coordination Practices

• Stories- Balance desires and possibilities

• Evolution- The plan learns, too

• Development- Execute the evolving plan

Business Justification

• How do you focus the early efforts of development?

• Create a simple projection of investment, payback and risk for five years

Year Cost Revenue Probability1 1.000.000 0 100%2 1.500.000 500.000 90%3 1.500.000 1.500.000 60%4 2.000.000 3.000.000 40%5 2.000.000 5.000.000 35%

Interest 5%Expected Value: -616.924

Write Story

• How do you learn enough about Business’ needs to plan?

• More detail reduces risk of missing something import, but slows process and adds inertia

• Write the stories the system must support as a name and paragraph on an index card

Story Example

• First release of Chrysler payroll started with 153 stories, growing to around 185 after 9 months of development

Ohio Union Dues

Employees at the Dayton plant pay $15/month union dues, except EIDs 48727 and 87728, who pay $10

Estimate Story

• How do you estimate the effort required by a plan?

• Interaction between stories can safely be deferred

• Estimate actively- build and discard prototypes

• Estimate on cards in “Ideal Engineering Weeks”- how long if you could just do it?

Commitment Schedule- Prepare

• Business sorts stories by priority– Must have or system won’t run– Contributes to business value– Nice to have

• Development sorts by risk– Know exactly how much work– Know about how much work– No idea

Commitment Schedule

• Establish velocity- developers * weeks / load factor (measure, mostly likely 2-3)

• Business deals out cards until target date is reached

• Put stories into 2-4 week iterations– Complete skeletal system after first iteration– Move risk and priority early– Not too much hard stuff at once

Recovery

• What do you do when your estimates are too low?

• First, examine your process to see if you can go faster

• Ask Business for minor reductions in scope that greatly reduce effort

• Ask Business to defer some stories

New Story

• What do you do with a new story?

• Issues– Development wants to be responsive– Development doesn’t want to be interrupted

• Do what you can do:– Business writes story– Development estimates– Business discards that many weeks worth of stories

Re-estimation

• What do you do when the plan is getting stale?

• No plan survives contact with reality

• Keeping the plan alive encourages communication with Business

• Re-estimate the stories remaining in the plan based on experience

Iteration Plan

• How do you plan in detail?

• Break the stories for an iteration into tasks

• Team members sign up for tasks

• Task owner estimates task in “ideal engineering days” (* load factor)

• If a developers has too much to do in the iteration, shift tasks around or redue scope – Do not reduce task estimates without a great reason

Development Episode

• How do you develop?

• Take a task card

• Find a partner

• If necessary, ask the customer for test data and explanation

• Cycle: Write a test and make it work

• Integrate

Continuous Integration

• How do you integrate development from different developers?

• To often and the overhead is too much

• To infrequent and trouble arises

• Integrate after no more than half a day or a day’s work on a task

• If the unit tests aren’t 100%, you broke them, so you fix them– Use a machine to single thread integrations

Coordination First Steps

• Write stories- use little pieces of paper

• Test/Code/Integrate in two hours

• Write game-like rules for changes to the plan

Conclusion

• Use as little process as possible

• Treat all practices as experiments

• Make changes piecemeal– Code– Process

• Start with testing, build from there