Embrace Change!

avijeetd@yahoo.com and satyabrata_dash@yahoo.com

Introduction

No process makes up for lack of talent and skill.

If you have wondered whether Extreme Programming is just another process, whether Extreme Programming is a panacea to process diseases, or what will happen to SEI CMM and RUP (Rational Unified Processes), once everybody goes extreme, then read on and find out why Extreme Programming is making waves in the developer world.

Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing high-quality working software that provides the highest return on investment for the customer in the fastest way possible. XP is extreme in the sense that it takes 12 well-known software development "best practices" to their logical extremes. The key focus in XP is Customer Satisfaction and making frequent releases of working software satisfies the customer.

Traditional Processes and XP

1. Waterfall model

The Waterfall Model consists of the following steps:

• Requirement.
Requirement of business functionality, expectation from system, non-functional requirements like performance requirement.


• Analysis.
Determine how these requirements will be accommodated in the system. Extensive communication between the customer and the developer is essential.


• Design.
Identify in detail how the system should be constructed to perform necessary tasks. System Design phase is focused on the data requirements, the software construction, and the interface construction.


• Coding.
Application is developed using specific programming languages in this phase. Developers are handed out the design specification document and developers are held responsible for building the system.


• Testing.
Testing is performed to ensure that system is working correctly and efficiently. Testing is generally focused on two areas: system testing and integration testing. Once these testing cycles are completed, the end user performs user acceptance testing (UAT) and accepts the system.

2. RUP (Rational Unified Process)

The major drawback with waterfall model is the visibility into project progression. Customers cannot see the application working until the entire application is completely built, tested and delivered. The time to market can be fairly high in complex projects and in dynamic business environment; the project may loose potential market opportunities.

RUP solves these problems to a far extent by introducing iterative development model. A project is divided into number of logical iterations and a project is delivered number of times to the customer and not just once, so that customer can play a valuable role in providing feedback and assessing the progress.

RUP divides the life cycle of a project into four phases.

Inception-specifying the project vision

Elaboration-planning the necessary activities and required resources; specifying the features and designing the architecture

Construction-building the product as a series of incremental iterations

Transition-supplying the product to the user community (manufacturing, delivering, and training)

 

 

 

 

Why another process?

If you have adopted Waterfall model, RUP (Rational Unified Process), CMM (Capability Maturity Model) and still see one of these problems, then it is indicative that your process is broken.

Deadlines are frequently missed:

When it comes to delivering the software, you tell your customer that you have to postpone the date because of unavoidable reasons.

Business changes can't be incorporated easily:



If your customer asks for a change, you become horrified, because, you think the change will break your design, make your system unstable and you might risk introducing too many risks.

High defect rate:



Customer finds lot of defects even after system was deployed to production. You do a bug fix and customer reports two new bugs.

Morale of the team is low:



Team members put lots of long hours to finish the project, yet, the project doesn't get over, customers have too many complaints and therefore, team members are unhappy about everything they do.

Unhappy customer:



Customer is unhappy about project slips, bad performance of the system and customer feels the system was not implemented the way it was asked for.

Unused functionality:



Functionality is built, and delivered, but never used in production.

Extreme Programming is not just another process; it is about set of software development discipline that competes with high ceremonial processes to get a smiling customer and energetic developers.

The practices are nothing new to developers. Successful developers have practiced these disciplines for long period of time. XP collates all those best practices and instills discipline and tries to get highest return on investment for the customers.

So let's find out what XP can do for everyone. Before we read on XP practices, believe in the Agile Software development manifesto.

The agile software development manifesto reads:

 

Extreme Programming (XP)

XP believes in the philosophy that "Change is the only constant". So XP always embraces changes instead of trying to resist the change. The XP practices make this happen more easily by focusing on test driven development and refactoring.

12 XP practices

XP has set of simple rules and practices. These rules are applicable to different stages of software development like Planning, Designing, Coding and Testing.

Let's take an example and see how the 12 rules of XP are used in various stages.

Case Study:

Build an online trading portal site for iTrader inc., one of leading security brokers of the country. iTrader wants that the user should be able to login to the online system, view the stock price, and trade for a specific stock.

The application will be built on J2EE platform and deployed on Weblogic server. A team of 4 people is identified to build the solution.

Now we will explain the 12 golden rules of XP and analyze the XP way of doing things.

The 12 fundamental rules of XP are:

The Planning Game

: Customer and development teams constantly work with each other to produce maximum business value. The planning game happens at various scales, but the basic rules are always the same:

Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4x6 cards.

Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).

Business then decides which stories to implement in what order, as well as when and how often to produce production releases of the system.

In our case study, iTrader identifies its delivery manager to be the customer representative for the project. So the delivery manager and the development team work with each other to identify the user story. A user story represents a user activity, completed through the system. One user story is that, user logs into the system and sees the trading home page. Other user story in our example is that user enters the required fields and buys 10 stocks using the system.

 

Small Releases

: Start with the smallest useful feature set. Release early and often, adding a few features each time.






Development team decides that the release will be made to customer every Friday. So for each week, three days are allocated for development, one day is reserved for integration and testing, and then customer demo is given on Friday morning and then planning for next week is done on Friday evening.

XP doesn't mandate the duration of release cycle. The releases can be made every one, two or three weeks depending on team velocity and complexity of the project.

System Metaphor

: Each project has an organizing metaphor, which provides an easy to remember naming convention.






The team used lot of trading metaphors such as margin trading, limit trading etc.

Simple Design

: Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what's needed to meet today's requirements.



There is no upfront time spent in design. Design is done only for the weekly iteration. The design is kept simple and yet, all fundamental objects oriented design principles are adhered. So there is no compromise made on the quality of design, yet, design is made simple enough so that everybody can understand and implementation can be done quicker.

Continuous Testing

: Developers write a test for before implementing the feature. No code is checked in without checking in a counterpart unit test class. When the suite runs, the job is done. Tests in XP come in two basic flavors.

Unit Tests

are automated tests written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit-testing framework, such as xUnit. The most commonly used unit test framework for java developers is Junit.

Acceptance Tests

(also known as Functional Tests) are specified by the customer to test that overall system functioning. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete. Ideally acceptance tests are automated using testing scripts.

iTrader developers decide to use Junit and MockStrutsTestCase for unit testing. Developers constantly measure the test coverage using Clover and the team consciously decides that there has to be minimum of 85% test coverage before code is deployed in production.

Refactoring

: Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn't break anything because you have the tests.



Refactoring heavily depends on automated unit testing. The automated unit testing gives the developer the confidence to change code and yet ensure that no other functionality was broken during the change.


iTrader development team decides to use Eclipse IDE, so that they can also use the IDE's refactoring features.

Pair Programming

: Two programmers sitting at one machine write all production code. Essentially, all code is reviewed as it is written. The pairs are changed frequently so that all developers can learn about all modules of the project.



This is one of the most controversial features of XP that teams find hard to accept. But, study shows that pair programming exponentially improves the productivity of the team members.


iTrader development team paired junior and senior team members so that juniors can learn quickly from senior members of the team and there would be constant code review.

Collective Code Ownership

: No single person "owns" a module. Any developer is expected to be able to work on any part of the codebase at any time.



Rotating team members across modules was done in this project. Team members like it, as they feel responsible for entire project.

Continuous Integration

: All changes are integrated into the code base at least daily. The tests have to run 100% both before and after integration.






iTrader team uses CruiseControl open source tool to set up continuous integration.

40-Hour Work Week

: Developers are rewarded to complete tasks on time. They get to go home after 8 hours of development work a day. Except for last leg of the project, overtime is considered to be a weakness of the team.



This is possible as team measures the velocity of the members each week. If the team fails to deliver on Friday, then the plan is adjusted so that high priority tasks can be completed on time.

On-site Customer

: Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead.



Delivery manager works as the customer for the development team.

Coding Standards

: Everyone codes to the same standards. All bad codes are refactored and unusable codes are thrown out. Everybody follows the same coding standard and the standards are constantly refined and improved.

iTrader development team used various open source tools to ensure that static and dynamic coding standards are being followed in the team.

Conclusion

We will discuss more on each of XP rules, practices and values in the coming articles. We will also discuss the pros, cons of using XP in large team, distributed team, fixed cost projects. We will also explain test driven design, and development with examples.

XP is not a revolutionary approach; rather it is based on set of guidelines practiced successfully in many projects. XP makes it easier to adopt, where predictability is difficult. The customer and developers work as a team to build working software. The team responds to change than following a plan.

Reference

Extreme Programming Explained by Kent Beck

Planning Extreme Programming by Kent Beck, and Martin Fowler

Extreme Programming, a gentle introduction

Agile Manifesto

CruiseControl, continuous integration toolkit

Junit, Java Unit testing framework

 

About Authors

The authors have 6 years of experience on enterprise application system architecture, design and development. The authors can be reached at avijeetd@yahoo.com and satyabrata_dash@yahoo.com respectively.