Who’s Afraid of eXtreme Programming

Written by Mike James

Thursday, 05 November 2020

Article Index
Who’s Afraid of eXtreme Programming
Agile programming
XP Practice

Page 3 of 3

XP Practice

If you are finding much that is reasonable in the XP philosophy then you might well want to know how to get started on using it.

According to Beck the design process is a cycle of: coding, testing, listening and designing – iterated over and over until the job is done.

This cycle can be expanded upon in the twelve practices of XP:

Planning game

The planning game is a method of determining the scope of the current iteration. What tasks are most important to the customer? The programmers and customers should work as a team discussing what is required. The programmer’s role in this is to outline to the customer the technical side of what is being requested – its cost, risks and so on.

In general the riskiest parts of the project should be worked on first. The planning game is recorded as “stories” - time lines of what is to happen. The customers finally decide which stories should fit into the current iteration.

Small releases

This is the practice part of the iterations philosophy. You release code to end-users as soon as you can. Don’t wait for the finished polished version – get the program into the field.

This not only helps with feedback but it provides maximum return on investment. The reason is the old rule that 80% of the function can be achieved with 20% of the effort. If you get the product out after 20% of the effort then you get 80% of the rewards.

Simple design

The simplest design passes all tests, has no duplicate code and is not convoluted. Defer complexity for as long as possible, hoping that it will go away or the customer doesn’t actually need it.

Testing

This is one of the key practices of XP and without it everything else will fail. Indeed if testing isn’t implemented properly then everything will fail.

If you are going to embrace change then you have to know that you aren’t doing harm. Code has to be considered as in a liquid state flowing from one iteration to the next and change has to be risk free. The only way to achieve this is to automate testing.

You need to write macros or use a testing harness to put your objects or modules through their paces and demonstrate that they work to specification. If you then change the code within a module testing can be performed to show that you haven’t broken it! This is sometimes called “test driven development” or "unit testing" and it’s the component of XP that is most often “stolen” and used in other methodologies or even just on its own.

Tests check the public interfaces of objects and a feature is deemed not to exist unless a test exists for it and its objects pass the test. In this way programmers do not think that their task is over when the feature is implemented – it has to be tested to exist.

Continuous integration

Big systems are often broken down into smaller modules. This is good as it makes simplicity easier to enforce but it brings with it problems.

There is a temptation to allow the fragments of the programming team to work on their own modules and only attempt integration when they are all well developed.

This can be a huge problem. Many a project has been seeming to go well with modules completed and working only to fall apart at the first attempt at building the complete system. Indeed even building the complete system can be so difficult as to be a stumbling block.

Client server n-tier architectures are particularly prone to this problem with teams able to design and build clients, middleware and servers in isolation and suddenly facing a completely different kind of problem when integration starts.

If, on the other hand, integration is part of the project from the word go then there should be no huge barriers to overcome to get it all working. This is, of course, all helped by the availability of build tools that will take the disparate parts of a project and automatically put them together into a finished whole.

Refactoring

This is another aspect of “embrace change”.

Refactoring is looking at the code you have, realising it’s not the best way to do things and changing it.

This means modifying object structures as well as methods. It also means changing code to take account of features your customer didn’t want in previous iterations but now does. Without refactoring you couldn’t simply concentrate on implementing the current iteration you would have to be constantly looking to the future requirements of the project and hence unable to keep things simple.

It is often said that once a project matures that adding two new features generally breaks at least one existing feature. Without refactoring, backed up by testing, this is bound to be true but with it code is safe to change.

Pair programming

This is probably the biggest revolutionary practice of XP and it is hard to justify if you don’t know why its being done.

Why have two programmers sitting over a keyboard when only one of them is actually programming?

In this case it misunderstands the role of the co-pilot because they aren’t just sitting there watching. The two work together using their combined knowledge and experience to program quickly and effectively. The code that is written is being constantly scrutinised by the co-pilot and there is nothing as guaranteed to make a programmer write good code than having it on display in real time! It also helps with refactoring, and the co-pilot can think of wider issues while the coder can concentrate on the details.

I know from experience that pair programming works and the only way to find out is to try it. There are spin-off advantages as well. The communication between the pair filters down to the whole group. Good ideas and techniques are spread by pair programming. It’s a great on-the-job training method and if pairings are changed often you end up with an evenly capable team with no weak members.

It also helps spot the weak members because no one wants to pair with them!

Collective ownership

The code, all of the code, is owned by all the team members. There is no sense in which a particular module or method is the property of a particular programmer and can’t be changed without his knowledge and permission. Pair programming helps stop proprietorial feelings towards code. Collective ownership means that there are no key members of the team who could wreck the project if they left and it means that there are no dark corners for mucky code to hide in. Pair programming also solves the problem of domain specialists. If you need numerical analysis to create a number crunching module then pair program it.

40-hour week

This one is easy to understand- no late nights, no sleeping over the keyboard and no mad panics to finish something. XP demands that you work at your best and if you can’t get it done in the time then ask for more time. Over night programming is sloppy programming and bugs are born at night.

On-site customer

The customer is part of the team and should be available when developers need to ask a question.

Metaphor

A metaphor is a common language used to discuss the project. This is the most abstract and variable part of the method. Customers and programmers have to share a common vision and this needs a common language.

Coding standards

If different programmers are going to read and work on each other’s code then there have to be standards of layout, naming of variables, design and so on. These are most easily implemented using automatic tools to check and format code.

The bottom line

It all sounds very exciting or very threatening depending on what investment you already have in existing programming methods. However it seems to be a recognition of the basic difference between a bridge and a program that makes agile and XP more appropriate philosophies for software.

Software and change go together the most important thing is to embrace change and to find ways of making change helpful rather than harmful.

Why Do We Try To Make Programming Like Something Else?

What makes a programmer

A Better Way To Program

Real eXtreme programming

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Kotlin Ktor Improves Client-Server Support
04/11/2024

Kotlin Ktor 3 is now available with better performance and improvements including support for server-sent events and CSRF (Cross-Site Request Forgery) protection.

+ Full Story

Random Gifts For Programmers
24/11/2024

Not really random. Not even pseudo random, more stuff that caught my attention and that I, for one, would like to be given. And, yes, if I'm not given them, I'd probably buy some for myself.

+ Full Story

More News