Apr 19, 2023

Extreme Programming

2

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

3

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

4

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 “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

For example, it is well known that software should be tested frequently during development

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

5

XP values Communication

Use simple designs and common metaphors, talk continuously with your programmers and customers

Simplicity Follow the KISS principle (“Keep It Simple, Stupid!”)

Feedback From the system: Unit tests From the customer: Acceptance tests From the team: Estimate the time to implement new requirements

Courage Code for today, not tomorrow Refactor as appropriate Be willing to throw code away

Respect Trust your team members not to submit nonworking code

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

Pair programming in this course

One purpose of the Friday lab sections is to get you started pair programming on each project

After lab, you should work together with your partner as closely as possible

I know this may not be easy for some of you At least trade email addresses, and work together that way Instant messaging is often better If you have programming problems, go first to your partner for help

Reading assignment: All I Really Need To Know About Pair Programming I Learned In Kindergarten, by Laurie Williams and Robert Kessler (PDF)

The URL is too long to post here, but it’s on the class web page (or you can just Google for it)

9

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 and run tests JUnit is a framework that makes this much easier to do

10

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

11

Coding standards

Coding standards make it simpler for your teammates (or yourself, weeks later) to read your code

Java has some very well defined conventions you should learn Some conventions are strictly mechanical, such as formatting

(spacing and indentation) Eclipse can, upon request, correct your 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

12

Simple design

“Do the simplest thing that can possibly work” Complexity to achieve program efficiency is almost always a very bad

investment Complexity to support future features is seldom a good idea

Program for the features you need today, not the ones you think you will want tomorrow

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

13

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

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

14

What I expect of you Work as closely as you can with your partner

I realize this isn’t always easy 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

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

15

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