Extreme programming for programmersExtreme programming for programmers

Kirill KalishevSPb Java Users Group

13 Oct 2001

TitleTitle

Key conceptsPlanningDesignProgramming

ContentsContents

Intent: to try to show programming in the eyes of the extreme programmer

Deliver value for the customerFlatten the change curveHave fun doing programming

The goalsThe goals

Customer valueCustomer value

Start

Planned result

Desired result

Conformance to a big up-front plan

Conformance to actual customer value

Change curveChange curve

We have to make it true!

Cost of change

RequirementsAnalysis

DesignImplementation

Test

Development lifecycle

Provided the change is cheap

Key concepts (XP values)Key concepts (XP values)

Communication• A project would fail if somebody doesn’t communicate something important

Simplicity• Do the simplest thing that could possibly work

• (win in changing it when it needs change)Feedback

• Optimism is hazard, feedback is treatmentCourage

• Don’t let your fears stop you from making great software

Values is what distinguishes bunch of individuals vs. team

Const

Manageable

Key concepts (four variables)Key concepts (four variables)

Time

Cost

Scope

Quality

The circle of lifeThe circle of life

On-site customer

Planning game

Acceptance testing

Short releases

Pairprogramming

Unit testing

Simple design

Refactoring

Communication Feedback Simplicity Courage

PracticesPractices

On-site customer

Planning game

Sustainable pace

Metaphor Simple design

Refactoring

Test first

Pair programming

Short releases

Coding standards Collective ownership

Continuos integration

Weakness of one is supported by strength of others

The customer + programmers = a teamThe customer is in the same room to give answers

• prevents programmers from putting their suppositions to code

The customer is logically the one• all stakeholders speak to programmers with one voice

Can’t find a customer?• does the project make sense?

On-site customerOn-site customer

Talking to the customer everyday is a key to success!

Customer

Planning game - bill of rightsPlanning game - bill of rightsProgrammers

The right to an overall plan(what/when/how much)

The right to know what is needed(clear declaration of priority)

The right to change mindanytime

(functionality/priorities)

The right to make & update estimates

The right to see the progress &be informed on any schedule changes

The right to produce qualitywork at all times

The right to get the most possiblevalue out of each programming week

The right to accept responsibilitiesvs. having them assigned

Customer

Planning game - the movesPlanning game - the movesProgrammers

Table

Defines stories(on index cards)

Say who much it costs(put estimates to cards),

go spike if needed

Defines what to do & what to defer (sorts by value) Sort cards by risk

The plan

Defines the plan(by time or by scope)

Commit to meet the plan

The team believes that the next iteration they will do the same amount of work as in the previous one

• Project velocity in terms of ideal engineering time (days/weeks/tomato hours) is calculated• All stories are estimated in the same metric• Each next iteration is filled with the stories whose summary estimates fills the current velocity

Planning game - yesterday’s weatherPlanning game - yesterday’s weather

The worst problem is not being behind the schedule as such, but not knowing about that

Release vs. Iteration planningRelease vs. Iteration planning

Customer

Programmers

Planning game

Release planning• by scope/by time

Iteration planning• by time (1, 2, 3 week iterations)• each iteration the project velocity is updated• task breakdown is done

12

n

Release

Iteration1

2

n

Release

Iteration ...

The whole team (customer + programmers) learns about the system

• Releases are done often• The customer has a working system at all times

Short releasesShort releases

Acceptance testingAcceptance testing

Customer Programmers

Defines acceptance criteria for each story

Make it automatic,make it pass

XP believes that the best strategy is to solve the most pressing problem while keeping most options

In design, it reflects in the following:• No up-front design, instead,

• Do The Simplest Thing That Could Possibly Work• rely on your ability to change it later, when you learn new things or new features will be really needed

• Do design all the time, as you go along• Design for the iteration works

Design strategyDesign strategy

Simplicity keeps most options!

Like drawing cool diagrams? Great! We like it too. However,

Minimize the time between making design solution and turning it into code

• Computer does’t understand diagrams, but does it for code• You should consider yourself just guessing until code is written

Start with a test, to know when you are done

On diagramsOn diagrams

Metaphor• The story both the customer and programmers share about how the system works

Metaphor covers most of what we call “architecture”

• System of names• Actors• Interactions

On architectureOn architecture

- Oops, it sounds like plumbing, right? - Yes, something like that. In this case water going through pipes is like a transaction. When at least one valve is closed -- no way to proceed- Cool, why don’t we call it pipes, water & valves- Okay, sounds like fun

1*

1

*

PipeSegment

Valve

Plumbing

A rule: Each line of code is written by at least two people

Pair programming is a dialog of two people• The driver - controls the keyboard, the mouse and actively works on implementation of the program• The observer - thinks more strategically, looks for errors, misprints & etc.• Partners change roles

No dialog - no pair programming

Pair programmingPair programming

Pair-programmed code is better written & structured plus it is done quicker!

Acceptance tests• Owned by the customer • Proves that the story is done in terms of the customer’s perspective

Unit tests• Owned by programmers• Test everything that could possible break• Written before production code• Always pass 100% in the integrated code

Acceptance vs. unit testingAcceptance vs. unit testing

You won’t win if you write a test that• doesn’t communicate any new things about how production code should work• is not gonna break

You will win if you write a test that• communicates what is needed from the production code• will ever show that something has broken down (which is inevitable) - Test Everything That Could Possibly Break• independent of others as much as possible

Unit testing - a betUnit testing - a bet

If you had to choose what to throw away, it should be production code, not tests

When to test? It is a normal way to program:• If you add a new feature, write a test before production code• If you fix a defect, write a test that would expose the defect, then fix it• Every time, before you integrate code, unit tests must pass 100%

Unit testing - XP style Unit testing - XP style

Don’t let the fear that testing can’t catch all bugs stop you from writing tests that will catch most bugs

Excuses for not testingExcuses for not testing

• I don’t have time• This can’t be tested• I don’t know how• It tests itself!• I already tested it once and I have not changed it. I am smart enough to know this works perfectly

XP is not about writing production code. It is about writing tests and making them pass.

Quality code • Runs all tests• Expresses every idea we need to express• Says everything once and only once• Have the minimum number of classes and methods consistent with the above

No production production code is considered existing without tests for that

Code qualityCode quality

No code is owned by an individual person• The team owns that (read - everyone in the team)

If you see the chance to put changes - just do it, but

• all unit tests must pass 100%• integrate asap, otherwise you will lose

Why is it better than personally owned code?• You don’t have to wait unit a responsible person will be available• You know better what you want

Collective code ownershipCollective code ownership

Conflicts are not a problem as such. You have tests, you integrate often so you are not afraid of conflicts

No code sits nonintegrated for more than two hours

• integration is not painful anymore, we do it several times an hour!

There is only one integration thread a time• to make sure you’re integrating only your changes (integration computer works)

All unit tests must pass 100% every time you integrate

Continuos integrationContinuos integration

An activity of changing structure without modifying behavior, aimed at:

• making the program easier to understand & cheaper to modify

A core activity to do a good program• start with a simple thing & refactor it later. You are not afraid of being wrong.

Refactoring essential? No, if you are• omniscient• perfect• and so everyone else on the team

RefactoringRefactoring

Refactoring is everyday disciplined activity. If you do more and more refactoring - it means you don’t do enough refactoring

If you add a feature• first look for chance to improve existing code, to make the adding easier• refactor• make sure unit tests pass 100% & integrate•write a test, put in new feature and make the tests pass again• integrate

If you see the chance to improve something - do it. Otherwise, you risk to run into debts.

Essentials of refactoringEssentials of refactoring

If you don’t want to do refactoring for yourself, do it for your team!

Looking at the code, you should not see who wrote that

Different coding styles should not be an obstacle to better understanding. Develop that, agree on that and follow that!

Coding standardsCoding standards

Any fool can write a program the computer can understand. Good programmers write programs other people can understand.

We do appreciate good comments. However, while development, we don’t write comments because:

• they often lie• they don’t provide feedback (computer doesn’t understand them!)• there are a lot of more reliable ways to reveal the intent

On commentsOn comments

If you feel you should put a comment, refactor you program first. Then, take a look again. You are likely to lose you will to put comments.

Productivity does not increase with hours worked sowe work 40-hour week to be fresh and eager

If we have to work overtime, we don’t do it more than a week

Sustainable paceSustainable pace

Simplicity is the art of maximizing the amount of work not done

• simplicity to do• simplicity to understand• simplicity to change

Complexity is like debts. The more we keep it complicated, the more money we pay for that

On simplicityOn simplicity

What may look simple for you, may not be the case for the team. The way is to learn, agree and follow. The whole team together.

Design is a kind of recognition of patterns - we call it “experience”

Design patterns (like ones from GoF) give us system of names, what promotes better:

• communication• understanding

Since patterns are goals for refactoring, learning refactoring techniques is essential as well

On design patternsOn design patterns

Thinking in patterns is not an evil. Narrow thinking is.

To realize if XP is for you or not• Practices are simple. Their interactions are not obvious. The most value on XP is in the mutual support of the practices

To ship software & have from it

Why is it worth trying?Why is it worth trying?

The inventors of XP• Kent Beck• Ward Cunningham http://c2.com• Martin Fowler http://www.martinfowler.com

Famous speakers & writers on XP• Bob Martin http://www.objectmentor.com• Ron Jeffries• Don Wells http://www.extremeprogramming.org• William Wake http://users.vnet.net/wwake

Pair programming & collaborative development

• Laurie Williams http://collaboration.csc.ncsu.edu/laurie/

Who is who in the XP worldWho is who in the XP world

Within SPb XP users group• http://groups.yahoo.com/group/spbxp

Come share experience!Come share experience!

You can reach me•by phone: +7 (812) 322-9526•web: http://www.kirillkalishev.com