Radical, Surprising, Extreme and they Work!

Programming and Methodologies: What went wrong?

The evolution of programming methodology

Programming by a maestro is something akin to an art form. Unfortunately, not only is it possible to develop beautiful programs, it is also possible and (quite common) to develop programs that are an abomination. I.e. they do not work, are impossible to maintain, and have been created with resources (time and manpower) that grossly exceed the original estimates. Many brilliant minds have worked to devise methodologies to discipline the programmer to create programs that are predictable and maintainable. The evolution of these methodologies followed roughly the following sequence:

1. In the 60's and 70's (Yes believe it or not some of us were writing code at that time!), it was just "dive into the code" (no documentation, no plan) and the classic rats nest programs were the usual result.
2. Programming rules and the structured programming concepts emerged but they did nothing to address the bigger issues. People, projects, costings, estimates etc.
3. New methodologies, inspired by the engineering disciplines emerged. The idea was to thoroughly plan the software through the various phases (some say to the nth degree), document it, get a sign off from the customer and then create it on time and to the schedule. The idea was to make software predictive. Unfortunately, writing software is very different to building a bridge. It is like forcing a gifted artist to paint by numbers! The methodologies themselves become enormous (some say monumental). The focus was on the bureaucratic processes which few really understood. The bottom line, ...with much anguish, it usually, (though not always) works but the software reflects the methodology. Big, slow, cumbersome, devoid of anything that resembles creativity. Oh and programmers hate it with a passion!

Enter the Agile Programming Methodologies

So, after many years of anguish, someone decided to reinvent the wheel and lightweight methodologies emerged. The main difference is that the focus is on Agility not Predictability. The methodologies are built around the fundamental tenets of good programming (well why not?) but are also sensitive to the psyche's of programmers, customers and project managers.

How exactly do these new methodologies differ and what are the advantages to be gained by them? In the next section, we will look at one such methodology. (Extreme Programming). As the name implies, the rules (or in some areas, lack of rules) are extreme but ... it really works! We are once again allowed to create beautiful programs and indeed, happy customers and projects that are completed on time and within the budget!

New Programming Methodologies: Radical, Surprising, Extreme and ....they work!

In the last section, we looked at the limitations of classical programming methodologies, which were designed largely for the engineering fraternity. As a reaction to these limitations, a new breed of lightweight, agile methodologies has emerged. These new methodologies offer a refreshing and effective alternative to how we organize and run software projects. In addition to the methods of programming themselves, the system also takes into account the psyche of the key players. I.e. the programmers, the managers, and last but not least the customer. To introduce these radical methodologies to you, we present here some of the characteristics of the Extreme Programming Methodology, which is one of the most successful around today.

Here is how it works:

(Differences from the conventional methodologies are shown in green.)
The customer writes down a user story (in his or her own words) for each function that is required of the application. Each User Story is no more than 3 sentences long.
The User Stories are used to define the test scenario and also as the basis of the release planning.
In the release planning, iterations are defined that are no longer than 3 weeks and no shorter than 2 weeks. The iteration is the heart of the process. Each iteration has a defined objective, and it starts with the writing of the test procedure that will define the successful completion of the iteration.

After the tests are written, the coding commences and all coding is done with two programmers to a computer!
No overtime is allowed and the programmers are encouraged to rewrite the code as often as possible.
If a bug is found, it is fixed immediately and a new test is created.
All the code is group owned and the customer is involved throughout the process.
Programmers focus on the current iteration and completely disregard any functionality outside the current iteration.
Once the iteration is complete, the next iteration commences, and so on, until the final Acceptance tests, wheron the product is released.

So what is the bottom line?

There are a plethora of benefits associated with this kind of methodology. It is fundamentally agile and change is seen as something to be embraced not feared. The process moves steadily (in three week bites) to a successful product without nasty surprises at the end of the project. But above all, everyone (project managers, programmers and especially the customers) find the processes fulfilling and rewarding. We find ourselves creating beautiful programs and indeed, happy customers and projects that are completed on time and within the budget!

This has been a very brief introduction to Extreme Programming. For your information, Extreme Programming is the methodology adopted here at St James Software.

Click here to view our Price List.