Agile Programming

The alternative is to admit that the really great thing about software is that it is easy and cheap to create and change and any programming method should start off with this as a basic belief.

Programming methods should concentrate on finding ways of creating a good final end product making use of the ease of creating and changing code. This is the basic idea of Agile Programming (or AP) and eXtreme programming is one branch of this general approach.

Notice that AP isn’t just advocating sitting down and writing something and then changing it as often as needed in an ad hoc fashion. If it was then it would be something to be feared as it would hint of a return to the bad old days when programmers just made it up as they went along.

It is clear that to achieve something better AP and XP have to build ways of implementing the changes so that the result remains clear and elegant. In fact the purpose of the changes should be to make the program more elegant not just to add some feature or tricky improvement.

With this philosophical change in mind, i.e. that programmers should be agile rather than ponderous, the time has come to look in detail at the ideas of XP in particular.

The way of XP

It is important to note that XP isn’t a single programming method and people are very much still arguing about the parts of it that are good and not so good. However before you can accept or reject it you need to know what it is and this brings us to the "Twelve Practices of XP".

As you read through the “Twelve Practices of XP” keep in mind that you are free to disagree with any one without having to reject the Agile Programming, or even the XP, philosophy in its entirety.

The twelve practices of XP and their relationships

You can even take the parts of XP that suit you and mix them with more traditional programming practices such as UML. Indeed some of the ideas in XP are “borrowed” from other design philosophies anyway!

Kent Beck's four values

The most influential book on XP, and the one that more or less invented it, is “EXtreme Programming EXplained: Embrace Change” by Kent Beck. In it Beck first identifies the four values of XP.

You could say that he defines its basic tenet in the subtitle to the book – “Embrace Change”. The four values constitute what should be admired and what should be the goals of the programmers in any team.

The four values are:

Communication

Programmers involved in a group design have to communicate with one another so that no single programmer is indispensable.

Other methodologies pay lip service to communication but allow particular programmers to become expert at one part of the project or another. XP enforces the communication at a much deeper level by introducing the idea of pair programming. That is, when some code has to be written one programmer sits at the keyboard and another watches. In this way the code is at least the creation of two programmers rather than one. Pair programming is one of the most controversial and high profile of the ideas in XP so it is worth discussing at length later. There are also many other XP devices for ensuring better team communication.

Simplicity

This is the continuing strand of previous design philosophies. Simplicity is better because it is easier to make sure code is correct and to change as required. Conversely complexity is bad and should be actively avoided. In particular, don’t choose a technology – ASP, EJB or XML – just because it sounds good. Find out what you want to do and choose the necessary technology to make it work.

Feedback

Find out how well you are doing as soon as you can. This involves active testing of the code and of the finished product. Use small iterations to show the customer and the rest of the team what state the project is at. Don’t wait until you have something impressive to show the client – show the first possible working anything. Early feedback is cheap to act on. Late feedback is more of a problem!

Courage

A strange value to find in a list of programming aims but if you have been involved in any sort of large project you will know what Beck is getting at!

You have to be brave enough to do what you know is right. If you are part of a project and you know that some subsystem is just plain wrong and needs fixing then you have to say it and make sure that others know this. If the team has courage then it will be fixed, even if it causes deadlines to slip or costs to overrun. However if you stick to XP methods the argument goes that you need a lot less courage because you should find yourself in these nasty positions a lot less often.

The Five Principles

After the four values Beck went on to define Five Principles. With hindsight these are very similar to the four values but they are supposed to be interpreted as what you should do to make a method XP:

Provide rapid feedback

See the value of feedback explained earlier.

Assume simplicity

Treat every problem as if it was simple until it proves to be not so. As most problems are indeed easy to solve this avoids over-design and building in unnecessary features and facilities. The most controversial part of this is that it also implies that you should design only for this iteration. Don’t worry about what the customer might need in 12 months time – design for his needs NOW.

Make incremental changes

This not only improves the flow of feedback it also backs up the simplicity principle. Assuming simplicity means you only design for the current iteration and only bite off a little of the complexity at a time.

Embrace change

The fourth principle is also the mantra of the XP programmer.

If you assume that the design is not fixed then you can make incremental changes and you can assume simplicity. It is only by not being afraid of change and by actively welcoming it can you face the task of implementing a system.

Many design philosophies assume that the customer has a requirement which has to be specified at the start of the project. From that moment on the requirement is cast in stone and is unchangeable. The task of the programming team is to build the system that the customer specified and if their requirements change well that’s a different project.

But wait, who’s the system for?

The customer surely and the old motto is that “the customer is always right”. We need to get away from the idea that the bridge, once under way, is fixed and cannot be changed and recognise the fact that software is changeable and that this is its best feature.

We must embrace change at every phase of development and use tools that make change easy, painless and safe.

Do quality work

This one seems so obvious but … sloppy code and cheap solutions are often the best way to meet a project’s goals. If this is the case then the project has the wrong goals and these should be changed. Every line of code written should be high quality and the tools should be made available to ensure this. Testing and certifying each line of code and making sure that each line is handled in the event/occurence of an exception is key to making sure that everything else concerned with quality follows naturally.

It has been said often that customers will forget that software was delivered late but the fact of living with software that doesn’t work lingers on!

<ASIN:1934356050>

<ASIN:0321146530>

<ASIN:3642042872>