You probably have heard of eXtreme Programming or XP. It's a type of agile software development and a lot of people think it's great. Some are trying to turn it into something more like software engineering and others are simply against it. So what is it all about and why does it ring true with some and makes no sense at all to others?

One of the things about eXtreme Programming (XP) that you are going to have to get used to is its association with dangerous sports. For some reason many XP books take white water rafting, canoeing or some other die-young sport to illustrate its basic ideas.

This is probably just a desire to make a break with the past and perhaps make something that might seem to some as tedious sound cool. Whatever the reason try to ignore it  because there is a lot of good sense in XP. 

Even if you don't swallow its arguments hook, line and sinker there are still ideas worth knowing and worth thinking about. 

If you are in a hurry and want to get on to the ideas of XP then skip to the next page. What follows is largely a summary of the problems that programming causes us that are unique to it. 

Programming is hard?

Programming is the simplest thing in the world.

But its also the most difficult thing in the world.

This is at the heart of our problem.

Some people do manage to pick up a programming language simply by reading the documentation and writing small programs. Once you get the general idea it really is easy but it’s just the start of the learning curve.

Ask yourself, if programming was easy why are there so many terrible programs around!

Early in the history of programming it was essentially a free-for-all. The low-level code forced programmers to write hundreds of instructions to achieve even simple things. The hardware wasn’t up to the job and this forced programmers to use dirty tricks to squeeze their programs into the tiny memory then available and to wring the last bit of performance from slow and feeble processors.

This caused a distortion that made people believe that good programmers were “tricky” programmers. There was, and still is a cult, of worshipping the programmers who can “hack it” and write code that does clever things in ways that are very difficult to understand.

This, however, is not good programming.

The problem with being clever and tricky is that you introduce even more complexity into something that was probably quite complex enough before you started to get clever with it!

The result is buggy code that works sometimes and crashes often. What is worse is that this code, being so complicated, is, by its very nature, next to impossible to debug.

This problem is worse if more than one programmer is involved in the project. Making changes to fix one bug is almost guaranteed to introduce new, and perhaps even-harder-to-find, bugs. And when it comes to extending the program things get worse. Each new feature impacts the stability of existing features and the entire program becomes increasingly unstable.

Structure

In the early 60s the first reaction to this messy programming was the development of structured modular programming.

It introduced the idea of restricting the range of possible expressions within a programming language to provide a simpler and easier-to-understand form of expression. A philosophy of clarity was promoted and this, combined with the idea of dividing a big program into smaller chunks, i.e. modules, was used to produce simplicity out of complexity. The notion of striving for clear, understandable program code was almost more important than the technical innovations that were introduced to make this possible.

If you think that this part of the story is past history I should reveal to you the terrible truth that there are many practicing programmers  who still think it’s a black art. Education is slow and in many ways the newer philosophies of object-oriented programming (see later) have taken the emphasis away from writing clean elegant code. You will still find programmers who defend their spaghetti code within otherwise well-designed object structures.

At the same time that the philosophy of clean, easy-to-understand code was being developed so were theories about how a program relates to the real world. The basic idea that a program was a model, or description, of some real world objects slowly developed and so did the programming philosophies and methods based on it.

Eventually all developed to the point where programming methodologies such as UML-based modelling were alternatives to programming rather than ways of doing it. UML – Universal Modeling Language – was designed to allow programmers and a range of other people, perhaps including the client, to construct a model of the part of the world relevant to the system, which included the entities that interact and how they interact. With the help of special tools, such models can automatically be converted into program structures in almost any “real” programming language. The programmer’s task is then reduced to filling in the code needed to make the methods do what they were supposed to. There’s still scope for making a mess of it but at least the overall structure of the program should be logical, understandable and easy to modify.

Software like a bridge

My description of the current state of programming methodology and the use of UML and tools based on it is sketchy to say the least, and probably irritating anyone committed to these methods.

What really matters is to characterize the philosophy in use today as based on “bridge building”. Software construction can be viewed as just another way of creating machines or structures. It’s just another branch of engineering where the constructional materials just happen to be slightly different. Hence we often refer to programming methods and philosophies as “software engineering” or something similar.

Now this can be no bad thing – can it?

After all, the other products of engineering science don’t behave as badly as the average program. Bridges don’t fall down. Well, they usually don’t fall down. And lifts, houses, cars and electronic systems tend to work reliably to the point where it generally isn’t worth designing them to be easy to fix.

Refactor that!
Credit: Xpda

So why not apply the same rigorous methods to software?

This is indeed very appealing thinking. Instead of sitting down and dashing off a half-thought-out program you should sit down and design it first. You need to consider what makes it work, how best to make it work and how to build strength into it so that it doesn’t break. You should build programs like bridges out of solid components that have been carefully designed to do their job.

Again I’m glossing over many subtle points and doing the idea great injustice in the process, but programming aspiring to heavy engineering isn’t a bad way to express the principle! It is difficult to see what could be wrong with this design-carefully, build-once principle but according to many XP enthusiasts it is plain wrong. It’s obviously wrong.

Why treat programming like engineering when the very essence of software is that it is easy to change?

If you get the calculations for the girders of a bridge wrong then changing them when the bridge is three-quarters built is very costly – you have to get it right first time. If you need to change some aspect of a program then it shouldn’t be anywhere near as difficult or costly.

Of course if you have used a design method that starts off with the idea that change is bad because changing software introduces bugs all over the system then you might well not see it this way. However, if you select a philosophy that tries to make programming immutable in the same way that ironwork is then you are going to see change as undesirable, even when it is in the very nature of the materials you are working with.

<ASIN:0321278658>

<ASIN:020161622X>

<ASIN:0596003870>

<ASIN:0132350882>