Extreme Programming Evaluation & Review

INTRODUCTION:

If you're in the field of software development and/or software engineering you've probably heard, one way or another, about Extreme Programming. Extreme Programming can be considered more of a work ethic than an actual Programming paradigm in that it instates many control process in every day programming tasks.

Extreme Programming is one of the newer software engineering methods (Founded in 2001) developed by Kent Beck (One of the original 17 signatories in the Agile Manifesto). Its track record, after eight years of usage scenarios, is actually quite successful. Many companies attribute to the XP Principles which are geared towards customer satisfaction and rapid response to change.

WHAT EXTREME PROGRAMMING IS:

Extreme Programming is a software engineering discipline that is designed, from the grounds up, to allow flexibility in design, programming and testing in such a way that it can respond quickly to the changing requirements of customers. This can even happen late in the life cycle of a software development project and doesn't promote the creation of the classic notion that is patch developmevelopmennt.

At the same time, Extreme Programming follows the principle that two heads are often better than one in that paired programming is highly encouraged in software development efforts. It has roles for users, designers, developers that allow them to work closely with each other which help in the way the methodology responds to changes in a design and in the resulting application.

THE RULES OF EXTREME PROGRAMMING:

Extreme Programming is entirely governed by a set of preset rules which when used together is designed to optimize the time spend on every aspect of software development. The rules are broken down into four phases as follows:

Planning

Of course, the planning stage is the beginning of any software development project. In the classic sense of the word, the planning phase is where meetings take places, needed forms, documents, dossiers are collected for the purpose to be understood and implemented (further down in the design and coding phases). This is where it all begins. The Extreme Programming rules for this phase are:

• User Stories are written.
• Release planning creates the schedule.
• Make frequent small releases.
• The Project Velocity is measured.
• The project is divided into iterations.
• Iteration planning starts each iteration.
• Move people around.
• A stand-up meeting starts each day.

Designing

At the design phase, most needed information is acquired, cataloged and referenced for the purpose of being taken, one at a time. At the design phase, there are usually two or three parts to consider. The first being the data entry forms. This is where data validation rules are determined for example as well as the data types that are to be used for the processing of the values. The second is the actual work (processing) to be done with the information provided. Does it need to be saved, is it used in search criteria on another form, is there any relationship between this form and the previous/next form in the list and so on. The last (not applicable to all forms necessarily) is the expected output of a given form. Is it input data for another process, is it a record in database file (or multiple database files). All these are accomplished using one or more design tools such as Data Floe Diagrams (DFD), Perhaps UML if OOP is to be used and so on. The rules that imply to designing are:

• Simplicity.
• Choose a system metaphor.
• Use Class, Responsibility and Collaboration (CRC) Cards
• Create spike solution to reduce risk.
• No functionality is added early.
• Re-factor whenever and wherever possible.

Coding

Again, in the classic sense of the word. All the charts, diagrams, DFDs are done at this phase, it's time to implement the solution using the programming language and programming paradigm that has been defined prior to the start of the coding phase. In XP it means that two coders will be working on the solution. Paired programming is the fastest way to get a unit out the door. One codes it, one tests it and reports problems. This team work goes on until the end of the project. More than one pair of programmers can of course work which means that different parts of the program can get done faster. The rules for the coding phase are:

• The customer is always available.
• Code must be written to agreed standard.
• Code the unit test first.
• All production code is pair programmed.
• Only one pair integrates code at a time.
• Integrate often.
• Use collective
• code ownership.
• Leave optimization till last.
• No overtime.

Testing

It's true that at least some testing has been done at the independent unit level during the pair programming session. Because in XP the test units are written first and then the actual module is run against the test units to evaluate if it works as expected at the coding phase. Since these 4 phases apply to smaller iterations of the big project a final test against the test units are done at the end of coding phase just to be sure that an integrated iteration is causing a problem somewhere else in the project. The rules for the testing phase are:

• All code must have unit tests.
• All code must pass unit tests before it can be released.
• When a bug is found tests are created.
• Acceptance testing is run often and the score is published.

As you can see here this rather short list of rules (compared to some other methodology) is actually surprisingly simple. Likewise, the relationship between each step in each part of the development phase as well as the relationship between each of the phases themselves all contribute to providing a fast changing working environment that can easily, when all elements are present, adapt to any new situation, change, additions because everything and everyone as so closely related to the outcome of the software development process.

Based on experience and projects that were created using Extreme Programming, projects that are object oriented in nature are typically better managed because the object often represent a great complete functional iteration that is self sufficient and easy to create test units for as independent iterations. However, modular projects when organized accordingly can play the same role so Extreme Programming is good for all kinds of projects.

EXTREME PROGRAMMING RUMOR EXPLORATION:

Extreme programming is roughly about 8 years old (at the time of this writing) and although computers and computer programming are usually rapidly changing to adapt to new reality of the hardware and the increasing needs of the users, in the software engineering world, 8 years makes extreme programming rather new compared to other methodologies. As such, Extreme Programming has accumulated rumors along the way as it tries to make its way into the software engineering methodologies. In the last revision of the SWEBOK (The SoftWare Engineering Body Of Knowledge) Extreme Programming was not added to the body of knowledge. Perhaps it will make it into the next revision as it continues to be used successfully in more and more types of projects.

Let's take a look at some of the more widespread rumors about Extreme Programming that might explain why it was not voted in the SWEBOK reference:

• Extreme Programming lacks some major organization:
  To the eyes of software engineers this is the most widespread, because of the tight practices of extreme programming it is often accused of not seeing the bigger picture of the project because programmers seem to be working on all parts of the project which they believe makes it hard to keep track of what exactly gets done. However, Extreme Programming is all about measuring actual work done, about giving fast feedback to the customers so that they can see what's going on more often and be able to play a role in what's to be done. If something needs to be changed, having the customer right there helps in knowing that in the first place as well as what the changes should be. Often a reality can change right in the middle of a project, not because of the customer per se, but rather because standards and other factors influence or categorically change what is expected of a current functionality. The ability to change to accommodate this new reality is one of Extreme Programming strength.




• Extreme Programming is not good for every project:
  What software methodology is? When this rumor was raised, Extreme Programming was but a few years old. It wasn't used in many projects because it was a brand new method. This rumor today is proving to be wrong. Indeed Extreme Programming practices seem to offer concrete advantages on more and more different types of projects. This includes games, compilers, business applications, tools and utilities, reporting techniques and more. Is Extreme Programming the perfect methodology for all types of projects? Only time will tell, but it's clear that Extreme Programming today is making its way towards that goal more and more with every project that it is used for. This is independent of industry as well. Scientific, medical, telecommunications, stock market are all fields extreme programming as been used with a rather good rate of success. And all this is helping it become more and more popular, which then gives it better reasons to be used in upcoming projects as it makes its reputation one project at a time. We'll see where Extreme Programming stands in another five years.

These are the two major rumors. There are more of course, Also, many existing rumors were created because Extreme Programming was not known or used. Hence, people didn't understand what it was all about. Extreme Programming has failed in some projects. However, the story doesn't say that extreme programming itself failed or if the group of developers that tried to use it failed at using it the right way (since some of the notions of extreme programming are very different from the conventional programming practices it's quite possible that some of it was too different and therefore the people trying to use it couldn't part themselves that far away from the ways of software engineering they already knew). After 8 years of existence, I'd be curious to see how Extreme Programming would do if it was to be used on the exact projects where they were deemed a failure especially now that extreme programming rules and principles are probably more understood than it was when these projects failed.

IN CONCLUSION:

The best advice I can give you is to use the reference links I provided below and read about Extreme Programming. See what you can make of it, create your own conclusions and make your own opinion about it. As far as I'm concerned I like what Extreme Programming is all about. Not just because it's a brand new methodology (a new methodology is probably long overdue in the software engineering field) but because of the way that even if a rather big group of people are involved in a given project, Extreme Programming really seems to allow to shift the project around, remove or change existing functionality with minimal impact on other existing functionality since testing is performed before, during and after each of these changes.

All in all, Extreme Programming is proving itself successful on big projects. Since these big projects are the projects that represent the biggest time and money investments it's only natural that this be the first place where the rate of success can be quantitatively measured and seen. If you have 2 or more people (an even number of programmers works best for pair programming) any project, whether commercial or personal should benefit from the same advantages that the bigger projects have seen. In fact, in a smaller group of developer it is probably easier to maintain a tight control over the development of rugged test units and functional code for a given project. But don't take my word for it, take a look around, read and learn about Extreme Programming, find it where it's been successful, where it failed and why. And then decided of extreme programming is for you.

REFERENCE LINKS:

Here are links of websites I've used throughout this evaluation document. You can find a whole lot of details, explanation and examples concerning the Agile Methodologies and more specifically about Extreme Programming.

• The Agile Manifesto
  This is the main website of the original and maintained Agile Manifesto. Where you can learn about the Agile Methodologies of software engineering as well as the founders of the Agile method.

• Extreme Programming
  This is the website where learning about Extreme Programming begins. They cover what Extreme Programming is, when it can and should be used as well as many definitions of everything that Extreme Programming entails.

• The Software Engineering Body Of Knowledge
  This website is where you can read about and get the guide to the Software Engineering Body Of Knowledge reference. This represents one of the greatest efforts at taking everything there is to know about Software Engineering, categorizing and cataloging them all into one central reference.