Extreme Programming

Since this is a blog about my Software Engineering class, I figured I would cover a Software Engineering strategy (?) called eXtreme Programming also known as XP. So what is XP?

extremeprogramming.org states:

Extreme Programming (XP) is actually a deliberate and disciplined approach to software development....
XP is successful because it stresses customer satisfaction. The methodology is designed to deliver the software your customer needs when it is needed. XP empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.
This methodology also emphasizes team work. Managers, customers, and developers are all part of a team dedicated to delivering quality software. XP implements a simple, yet effective way to enable groupware style development.
XP improves a software project in four essential ways; communication, simplicity, and courage. XP programmers communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. With this foundation XP programmers are able to courageously respond to changing requirements and technology.
XP is different. It is a lot like a jig saw puzzle. There are many small pieces. Individually the pieces make no sense, but when combined together a complete picture can be seen. This is a significant departure from traditional software development methods and ushers in a change in the way we program.

There are 4 major rules/strategies that are followed:

1. Planning
• 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.
• Fix XP when it breaks.


2. Designing
• Simplicity.
• Choose a system metaphor.
• Use CRC cards for design sessions.
• Create spike solutions to reduce risk.
• No functionality is added early.
• Refactor whenever and wherever possible.


3. Coding
• The customer is always available.
• Code must be written to agreed standards.
• 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.


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

We have covered different types of development cycles, i.e. Cascading/waterfall design, XP on the other hand is a bit different. Below is the flow chart used for development.


This type of methodology may seen like a good practice, it does have its own set of controversial aspects. Wikipedia lists some of them such as:

• Requirements are expressed as automated acceptance tests rather than specification documents.
• Requirements are defined incrementally, rather than trying to get them all in advance.
• Software developers are required to work in pairs.
• There is no Big Design Up Front. Most of the design activity takes place on the fly and incrementally, starting with "the simplest thing that could possibly work" and adding complexity only when it's required by failing tests. Critics fear this would result in more re-design effort than only re-designing when requirements change.
• A customer representative is attached to the project. This role can become a single-point-of-failure for the project, and some people have found it to be a source of stress. Also, there is the danger of micro-management by a non-technical representative trying to dictate the use of technical software features and architecture.

Personally, I have some reservations regarding this methodology and don't fully believe in all of the tenets. Also I believe testing is perhaps the most beneficial aspect. I haven't worked at any professional software development companies, so I am not sure how a lot of Software Engineering practices are put to use. The only real work I've done was with Pfizer, however, I was just an intern and was given my subset of work.

Finally, the name is horrible. I don't understand why they decided to use a name with 'extreme' in it. I feel like the creators of this methodology are trying to entice me to use it like Mountain Dew commercials. Should I be writing my code while skydiving, skateboarding, or even snowboarding? I don't think so. There is nothing extreme about this, it is only a different way of looking at doing things.

Have a nice day....