Extreme Programming
26-Jul-16
Software engineering methodologies


A methodology is a formalized process or set of practices for
creating software
An early methodology was the waterfall model, so named
because each stage flowed into the next, with no backing up to a
previous stage



The stages were: Requirements  Design  Implementation 
Verification  Maintenance
The waterfall model has never been regarded as a “good” model
Methodologies are subject to fads, and are frequently imposed on
programmers by management



Some methodologies are bad—even ridiculously bad
This doesn’t mean all methodologies are bad
However, a single methodology doesn’t work for all cases
2
Agile programming methodologies

There are (at least) two serious problems with the
waterfall model:



It assumes that there will be no unforeseen difficulties in the
software development
It assumes that the customers know (and can specify) what
they want, in extreme detail
Agile programming methodologies (of which there are
several) assume:

Customers can best discover what software meets their needs
via frequent iterations


Hence, communication between customers and developers is vital
Requirements will need to be revised, probably multiple
times, during software development
3
Extreme programming


In this course we will draw on a number of ideas from one particular agile
methodology, Extreme Programming (XP)
The basic idea of extreme programming is to take to an extreme each of
several known good practices


For example, it is well known that software should be tested frequently during
development


“The first time I was asked to lead a team, I asked them to do a little bit of the
things I thought were sensible, like testing and reviews. The second time there was
a lot more on the line. I thought, "Damn the torpedoes, at least this will make a
good article," [and] asked the team to crank up all the knobs to 10 on the things I
thought were essential and leave out everything else.” — Kent Beck
Extreme programming advocates testing code literally every few minutes, after
every minor change
Extreme programming works best for relatively small projects with a small
number of good programmers
4
XP values

Communication


Simplicity




From the system: Unit tests
From the customer: Acceptance tests
From the team: Estimate the time to implement new requirements
Courage




Follow the KISS principle (“Keep It Simple, Stupid!”)
Feedback


Use simple designs and common metaphors, talk continuously with your
programmers and customers
Code for today, not tomorrow
Refactor as appropriate
Be willing to throw code away
Respect

Trust your team members not to submit nonworking code
5
6
XP practices

Fine scale feedback






Pair Programming
Planning Game
Test Driven Development
Whole Team




Continuous process



Continuous Integration
Design Improvement
Small Releases
Shared understanding

Coding Standards
Collective Code
Ownership
Simple Design
System Metaphor
Programmer welfare

Sustainable Pace
Source: http://en.wikipedia.org/wiki/Extreme_programming
7
Pair programming is...

TWO programmers working side-by-side, collaborating on the same design,
algorithm, code or test. One programmer, the driver, has control of the
keyboard/mouse and actively implements the program. The other programmer,
the observer, continuously observes the work of the driver to identify tactical
(syntactic, spelling, etc.) defects and also thinks strategically about the
direction of the work. On demand, the two programmers can brainstorm any
challenging problem. Because the two programmers periodically switch roles,
they work together as equals to develop software.
--Laurie Williams
North Carolina State University Computer Science

Source: http://www.pairprogramming.com/
8
Test-Driven Development (TDD)


TDD is a technique in which you write the tests before you
write the code you want to test
This seems backward, but it really does work better:





When tests are written first, you have a clearer idea what to do when you
write the methods
Because the tests are written first, the code is necessarily written to be
testable
Writing tests first encourages you to write simpler, single-purpose
methods
Because the methods will be called from more than one environment (the
“real” one, plus your test class), they tend to be more independent of the
environment
To do TDD, it must be easy to create tests, run tests, and
immediately see the results
9
Continuous integration



Unit testing is testing a single, more-or-less independent
part of a program in isolation
Integration testing is testing the complete program with
all its parts, to make certain they all work together
Continuous integration is performing integration tests
frequently (usually daily)


Continuous integration is more important on larger projects
For class projects, last-minute integration is still a bad idea
10
Coding standards


Coding standards make it simpler for your teammates
(or yourself, weeks later) to read your code
Most programming languages have some very well
defined conventions you should learn

Some conventions are strictly mechanical, such as formatting
(spacing and indentation)


Some IDEs can do the formatting for you
Some conventions require human intelligence



Use meaningful names, with the correct part of speech
Use adequate comments, written for the correct audience
Prefer clearly written code to “clever” code
11
Simple design

“Do the simplest thing that can possibly work”



Program for the features you need today, not the ones you think
you will want tomorrow



Complexity to achieve program efficiency is almost always a very bad
investment
Complexity to support future features is seldom a good idea
With good unit tests, you can easily refactor (“revise”) your code to do
additional tests
YAGNI -- “You ain’t gonna need it”
Follow the DRY principle: “Don’t repeat yourself”


Don’t have multiple copies of identical (or very similar) code
Don’t have redundant copies of information
12
XP in this course


Do pair programming in labs, and work as closely as possible
with your partner outside labs
Use TDD (test-driven development) as much as possible

Write tests for your own code, not for your partner’s code






We have learned the hard way that it doesn’t work for one person to write
code and the other person to write tests for that code
However, this really has to wait until you learn about methods and about
JUnit
Stay in touch with your partner, and integrate your code as
frequently as feasible
Follow the defined coding standards, including those for
documentation
Keep your code as simple as possible
You and your partner should turn in one copy of your program,
with both names on it
13
What I expect of you

Work as closely as you can with your partner


Don’t just “contribute” your share of the code—also review your partner’s
code, checking for problems



It’s okay to criticize your partner’s code; it’s not okay to criticize your partner
Don’t take suggestions/criticisms/comments personally—any code can be
improved
You can use all the Java you know, if your partner also understands it



I realize this isn’t always easy
If I haven’t covered something in class (or even if I have, but your partner
doesn’t know it), it’s your job to explain it to your partner
If you don’t understand something in your partner’s code, ask them to explain it
to you
Don’t:


Depend on your partner to do it all
Take off and do it all yourself
14
The End
“All methodologies are based on fear.”
--Kent Beck
“If we asked the customers what they
wanted, it would be devastating for the
project.”
--Team lead on a project that shall remain nameless
15