|
Extreme Programming and A Real Life Example
February 23, 2003
Extreme Programming (XP) is a relatively new approach to software development.
In the early 1990s, Kent Beck was thinking about better ways to develop software. He came together with Ward Cunningham and had experienced an approach to software
development that made every thing seem simple and more efficient. Ken and Ward discovered what made software development simple and what made it difficult during those
experiences.
As a result, in March 1996, Kent started a project at DaimlerChrysler using new concepts in software development which was namely the Extreme Programming methodology and XP has
been proven at cost conscious companies like Bayerische Landesbank, Credit Swiss Life, DaimlerChrysler, First Union National Bank, Ford Motor Company and UBS until now.
Many software projects fail due to:
Incomplete or under-estimated business and end user requirements
Inadequately set priorities which aren't based on actual business needs
Lack of communication and shared vision between team members
Disparate teams where noone really knows who is doing what and how
No senior management faith in what is being done
Bad and insufficient project planning causing significant delays or restructuring
Overly complex and inconsistent design and coding practices
Complex modules that take long time to develop without feedback and testing
Disparate modules that usually fail to integrate
Lack of an overall functioning system on which progress in seen
Extreme Programming improves a software project in four essential ways:
Communication, Simplicity, Feedback and Courage.
It works by bringing the whole team together in the
presence of simple practices with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.
In Extreme Programming, every contributor to the project is an integral part of the Whole Team. The team forms around a business representative called the Customer who works with them daily.
Extreme Programming teams use a simple form of planning and tracking to decide what should be done next and to predict when the project will be done. Focused on business
value, the team produces the software in a series of small fully-integrated releases that pass all the tests the Customer has defined.
Extreme Programmers work together in pairs (pair programming) and as a group with simple design and obsessively tested code improving the design continually to keep it always just right for the current needs.
The Extreme Programming team keeps the system integrated and running all the time. The programmers write all production code in pairs and all work together all the time.
They code in a consistent style so that everyone can understand and improve all the code as needed.
The Extreme Programming team shares a common and simple picture of what the system looks like. Everyone works at a pace that can be sustained indefinitely.
Below are some keywords or key concepts for extreme programming:
User stories
Release Planning
Small and Iterative Releases
Acceptance Test
Whole Team
Simple Design
Pair Programming
Test-Driven Development
Refactoring (improving and rewriting code)
Continuous Integration
Collective Code Ownership
Coding Standards
System Metaphors
Sustainable Pace
This very brief introduction to extreme programming can be augmented by information from resources like Extremeprogramming.org and
XProgramming.com.
Now, here comes some real life information related to extreme programming:
During the development of IMPRO (Development of an Image Processing Environment, B.Sc Thesis, 1993) we have used most of those extreme programming features prior to its debut in 1996.
Before starting to code, we have outlined the functionality of the system with our customer (Muhittin Gokmen - our adviser at the university) and established a memorandum of understanding.
During the development process, we came together 2 or 3 times a week to discuss what had been done and how the project was progressing with our adviser. This really helped keeping
the adviser informed and it was a good method of getting timely feedback for us.
Next step was setting the coding standards to be used and the modules that would make up IMPRO. We tried to keep the modules as simple and trivial as possible.
IMPRO development team consisted of two developers - myself and Fikret Ballikaya. We have coded most parts of the image processing environment in pair.
Pair programming is described as two programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer - the driver, has control of the
keyboard/mouse and actively implements the program. The other programmer - the observer, continuously observes the work of the driver to identify tactical
(syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem.
Because the two programmers periodically switch roles, they work together as equals to develop software.
Pair coding can be first perceived as waste of resources but it has been proven that it boosts productivity and significantly reduces bugs. It is also a good way of exchanging skills between the members of the pair.
This kind of development was especially helpful in user interface design and coding complex algorithms. At that time, it really reduced the amount of bugs that could have taken several tests to discover. It also helped improve the system by having continous brain stormings.
By coding in pair, both of us had complete command of the development process; what had been developed and for what.
Some modules were developed alone too. For example, I have developed the low level graphics routines, critical error handlers, disk handlers etc in Assembly Language. Fikret developed
some parts of the help system on his own. After those solo actions. we have always briefed each other on what we had done to keep the other one upto date.
After the development of the basic image processing infrastructure, IMPRO was always up and running and this enabled us to play with the system as a whole. All the additional modules
worked in conjunction with this basic system and we never had to sacrifice the system for integration activities.
Also, during the development process we have done extensive, incremental testing. We did not wait for the whole module to be developed inorder to be tested. After writing 2 or 3 functions that would perform a basic task, we have tested thoroughly what had been coded.
This kind of approach was crucial for a software development project that consisted of more than 40,000 lines of code. IMPRO had 20 C Language modules, 5 Assembly Language (x86)
modules and 9 executable helper applications.
Development process by means of the time spent was also extreme. We have done 10-14 hours of daily coding for about 4 months inorder to complete the project on time.
Result: Almost 100% bug free, functioning software delivered on time :)
© 2003 Ilker Atalay
|
