E0 257 - Software Architecture

Y. Narahari

Department of Computer Science and Automation
Indian Institute of Science
Bangalore - 560 012
INDIA

Extreme Programming Explained, Kent Beck
Extreme Programming, familiarly known as XP, is a discipline of business and software development that focuses both parties on common, reachable goals. XP teams produce quality software at a sustainable pace. The language and presentation in the book is appealing. It you are associated with software development and you think there is scope for improvement, then you must read this book. A must read for programmers. The book has 3 sections


The Problem:

This section describes the problem XP is trying to solve and presents criteria for evaluating the solution. There are some inherent risks in software development like, Schedule slips, Defect rate, Business misunderstood, Staff turnover etc. These have to be addressed in the strategy. Software development can be made more valuable by spending money more slowly, and earning revenue quickly, and by increasing options for business decisions. Cost, Time, Quality and Scope are the project variables. Of these Scope provides the most valuable control. The conventional assumption that cost of change rises exponentially over time may not hold in many circumstances. There is an analogy between software development and learning to drive a car. Both need making lots of small adjustments to keep it on track. This means there is a need for frequent feedback and many opportunities to make corrections at reasonable cost. Values that serve both human and commercial needs are communication, simplicity, feedback and courage. Some of the basic principles derived from these values are: Rapid Feedback: Helps programmer to quickly learn how best to design implement and test the system. Assume Simplicity: Do a good job (tests, refractoring, communication) of solving today’s job today and trust your ability to add complexity in the future when you need it. Incremental change: Big changes made all at once just don’t work. Problems are solved with a series of the smallest changes that make a difference. Embracing change: The best strategy is one that preserves the most options while actually solving the most pressing problem. Quality work: Quality isn’t really a free variable. The only acceptable values are ‘excellent’ and ‘insanely excellent’. The other less central principles that helps us decide what to do in specific situations are: Small initial investment: Too many resources too early in a project is a sure recipe for disaster. Play to win: Everyone is trying to develop “by the book,” not because it makes sense, but because they want to be able to say at the end that it wasn’t their fault, they were following a process. Local adaptation: All practices quoted in the book needs to be adapted to suite the needs of the project Travel light: Artifacts maintained have to be few simple and valuable. Honest measurements: Estimates like approximately two weeks is more trusted than estimates like 14.176 hrs. ‘Lines of code’ is not a useful measurement if code shrinks due to better programming.
We want to do everything we must do to have stable, predictable software development. But we don’t have time for anything extra.

The Solution

The practices for the basic activities of software development should help us flatten the cost curve. The weakness of one is covered by the strengths of the other. The individual pieces are simple; the richness comes from the interaction of these parts.
The Planning game: Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.
Small releases: Put a simple system into production quickly. Then make small releases containing the most valuable business requirements.
Simple Design: The system should be designed as simply as possible at any given moment. No duplication of logic, no parallel class hierarchies, minimum possible classes and methods.
Testing: Automated tests for all programs. If the tests are not automated, XP doesn’t work well.
Refractoring: Programmers restructure the system without changing the behavior to remove duplication, simplify or add functionality
Pair Programming: Two programmers at one machine write all production code.
Collective ownership: Any one can change any code anywhere in the system at anytime
Continuous integration: Integrate and build a systems many times a day, every time a task is completed.
40-hour weeks: Never work overtime second week in a row. It is not possible to work extended hours and still be productive.
The management strategy: Decentralized decision-making. Metrics are important to measure what is happening against what was predicted. Making more measurements won’t give better results. Coach everyone to make good decisions. Intervene when the team cannot solve problems. Keep technical people focused on technical problems and business people focused on business decisions. The project must be driven by business decisions, but the business decisions must be informed by technical decision about cost and risk.
Facilities strategy: Create an open workspace for our team, with small private spaces around the periphery and a common programming area in the middle.
Planning Strategy: Quickly make an overall plan, refine it further in on short time horizons so that there will be little inertia when we change it.
Development Strategy: Craft the solution for today’s problem today and trust that we will be able to solve tomorrow’s problem tomorrow.
Design strategy: Continually refine the design of the system starting from a very simple beginning. Remove any additional flexibility that doesn’t prove useful.
Testing Strategy: Write tests before coding and preserve these tests forever. Run them all together frequently.
Implementing XP

XP can be adopted one practice at a time, first addressing the most pressing problem of the team. On existing projects XP can be adopted starting with testing or planning strategies. An ideal XP project goes through a short initial development followed by a long production support and refinement and finally retirement when the project no longer makes sense. The roles to be filled in the XP team are programmer, customer, coach and tracker. The full value of XP will not come until all the practices are in place. Many of the practices can be adopted piecemeal, but their effect multiplies when they are in place together. Keeping all the practices together is hard. XP is not a good choice when working with big teams, distrustful customers, technology that doesn’t support graceful change, when the build process takes too long. XP can be a good choice for fixed price/fixed scope projects.

BACK TO HOME

 Modified by: Sandhya G & Shijesta Victor on 03.11.2003