|
|
APPLICATION DEVELOPMENT
An Introduction to Extreme Programming
 Learn the key practices of Extreme Programming and how this agile development methodology can improve the quality of your code and make your life as a developer more enjoyable.
What is Extreme Programming? Extreme Programming (XP) is a methodology for software development. It's one of the various methodologies that are collectively known as agile methodologies. Agile methodologies are known for their flexible and relatively less formal approach.
Though XP is by far the most prominently talked-about agile methodology, there are other agile methodologies, such as Adaptive Software Development (ASD), Crystal, Dynamic Systems Development Method (DSDM), Feature Driven Development (FDD), Scrum, and many more.
Before discussing the specifics of the XP methodology, I'll make sure you understand the general philosophy of the agile methodologies.
What are agile methodologies?
Agile development methodologies such as XP provide a useful middle ground between software development without any meaningful process and software development using too formal a process.
If you look at the history of software development projects across domains, organizations, and cultures, you'll find that software development has, by and large, remained a chaotic activity, without any formal design and without any concrete planning.
On the other end of the spectrum are formal and detailed methodologies, which emphasize planning and formalization. However, even the formal methodologies don't necessarily ensure success in software development projects. They're often regarded as too bureaucratic, and people usually resist them. Developers often end up complying with the requirements of these methodologies only because their organizations demand them to, not because the developers are truly enthusiastic about them.
Between these two ends of the spectrum -- chaos and bureaucracy -- lie the agile development methodologies, such as XP. Theses methodologies do include processes, but just enough to act as useful lighthouses, rather than becoming impediments to the actual software development.
Some common characteristics of agile methodologies
Some of the common characteristics of agile development methodologies such as XP are:
- They work well with changing requirements. Formal methodologies for software estimation and project planning work well if the requirements are clearly identified and they don't change. However, in most projects, the requirements do change during their lifetime (for whatever reasons), and therefore, you need methodologies that can adapt well to the changing requirements.
- They center around small iterations. Small iterations are easier to plan and monitor. They also provide early feedback. Agile methodologies recommend iterations of one to four weeks.
- They are people-oriented rather than process-oriented. Agile development methodologies truly empower the developers. The developers make all the technical decisions, they make estimates for work to be done, they sign up for tasks for an iteration, and they choose how much process to follow in a project.
Overview of Extreme Programming
The Extreme Programming practices are based on the experience of Kent Beck and Ward Cunningham from a number of projects in which they worked together. Over the years, they observed what practices worked well in software projects and what didn't, and fine-tuned their understanding to four key values and 12 key practices of XP.
Kent Beck wrote a book, Extreme Programming Explained (XPE), introducing the philosophy and practices of XP. This book remains the most popular source of reference and inspiration for the XP practitioners. (This book, I strongly believe, is a must-read for everyone involved in the IT industry, regardless of whether you're going to use XP in your next project. It offers a practical, down-to-earth, and logical explanation of XP's practices in a language that even a non-IT person can understand.)
One of the main planks of XP is it strongly emphasizes teamwork. Some of the XP practices, such as pair programming and collective ownership, require a team of motivated and committed people who blend well with each other.
XP also places strong emphasis on testing and refactoring. Many of the other XP practices (such as pair programming, small releases, collective code ownership, and continuous integration) are supported by testing and refactoring.
There are 12 key practices in XP, which I'll discuss in detail in the rest of this article. These practices revolve around four key values of XP: communication, feedback, simplicity, and courage.
12 practices of XP projects
The key practices of XP are as follows:
- The planning game
- Small releases
- Metaphor
- Simple design
- Testing
- Refactoring
- Pair programming
- Collective ownership
- Continuous integration
- No overtime
- On-site customer
- Coding standards
Testing
If I were to start with just one practice of XP, I'd begin with testing. The XP approach to testing is something that works well in any situation, regardless of whether you use XP or some other formal methodology or whether you use an object-oriented programming language for development or otherwise.
Mention testing, and the image that normally comes into most people's mind is something that's an inevitable pain, something you don't enjoy but you know you have to do. The reason behind that image is the way developers have traditionally approached testing: You write some code, run some tests over it, and determine that you've done your job. Later, when you start integrating various pieces of code, you discover bugs. You fix one bug, and another one surfaces; you fix that bug, too, but there's another one lurking nearby. By the time you think you're through with all the bugs, some older bugs might resurface, in addition to the many bugs that remain undetected.
The following scenario I encountered in a training session a few years ago is typical, although the problem and the participants may differ. I asked the participants in the training session to write a function in C for sorting an array. A few minutes later, a participant proudly announced he was finished. He demonstrated it by typing about five values in a random order, and the output came out, properly sorted. I took the keyboard and typed five different values, in a reverse sorted manner, and his program went into an infinite loop.
"Oh, I missed that one," the programmer said, and started pounding the keyboard. A few minutes later, he demonstrated that the program also worked with the reverse sorted array. But when I typed some values that were all equal, his program hung. A bit annoyed, he corrected his program again, only to find that if I gave it an array of one element only, it hung again. Many more rounds of corrections later, the program was working fine, or so it seemed to him. But when I again specified random-order input, the program no longer sorted the data correctly. The programmer couldn't believe that what has worked fine earlier was no longer working.
My approach to writing the sorting program (and this is the XP approach, as well) is to begin by writing some test data along with the expected results. First, write a small testing program that calls the sorting function with one set of test data, and compares the result with the expected results. Then have the testing program call the function with the second set of test data, and so on. Finally, have it print how many (and which) test cases failed.
Only after writing the testing program do you write the sorting function, and run all the test cases on the function by running the testing program. If any test case fails, modify the code and then rerun all the test cases again. Running all the test cases after each modification isn't as painful as you might think because this process is now automated, inside a testing program.
As you write your code and think of other cases when the sorting function will fail, add more test cases to your testing program. Even after you're fully satisfied that the code works, if you find a bug later, add another test case to the testing program to isolate the bug and rectify it.
As I said, because all the test cases are run by a testing program, the process is automated. Rerunning all the test cases after every modification becomes easy. It also gives you a sense of the progress you've made in your implementation and confidence to make any changes or improvements in the future.
XP recommends that you write unit tests for everything before you write the main code -- i.e., write the unit tests for sorting before you write the sorting code itself. Write unit tests for all the normal conditions, as well as for any unusual circumstances (boundary conditions, etc.) under which you need the code to work. Then write your code. Run all unit tests and automate this process to remove the tedium and boredom of the repeated testing.
Compile and run your code. If all tests pass, great! If one or more tests fail, modify your code and rerun all tests again, not just the ones that failed earlier. Repeat this process until all tests pass. Don't release any code unless it passes 100 percent of the test cases.
Later, if you find some problem with your code, add more unit tests to isolate the problem. Then modify your code to fix the bug, and -- you guessed it -- rerun all the tests.
Don't keep unit tests for different programs or classes separately. Maintain a single, universal unit test suite. As you implement more and more functionality in the system, keep adding unit tests for all your code to this single test repository.
So far, so good for unit tests. What about integrated tests? Well, somebody also writes acceptance tests for each use case ("user story" is the XP term for this). That person may be a customer or someone from the development team who's putting on the hat of the customer.
The acceptance tests are black box system tests that test an entire use case (user story). The customer verifies the acceptance tests are correct and reviews the test scores.
For automating the process of running Java unit tests, you might consider using a testing framework such as JUnit. JUnit is an open-source testing framework developed by Erich Gamma and Kent Beck, and you can find it at http://www.junit.org. It's a simple tool that lets you write, maintain, and run unit tests. Similar frameworks are available for some other languages, including C++ and Visual Basic.
Refactoring
Next in my list of XP features to incorporate is refactoring. What is refactoring? In short, it's improving the design of existing code. As Martin Fowler describes it in his book Refactoring, refactoring involves making changes to the internal structure of software so it's easier to understand and cheaper to modify without changing its observable behavior.
Suppose you've designed and implemented some code. It passes all unit tests as well as acceptance tests. Later, some requirements change, and you modify the existing code. Over a period of time, the quality of your design or code may degrade because of many small changes you've made. Then one day, when you're looking at that code for some more changes, you realize it could be cleaner, and cleaning it up might make it easier to read, understand, and modify further, and perhaps even more efficient. However, you're worried that making these changes could break something else in your system, and you don't know what that something else could be.
This isn't a problem if you already have automated unit tests and acceptance tests in place, and you understand the techniques of refactoring (and perhaps have the tools to automate refactoring).
Because you have the automated tests, you know the code you now have works. You make the changes you think will improve the quality of your code, and rerun all the tests. If they all pass, you've successfully refactored your code. If even one test fails, you know the problem lies in the change that you made, in which case you either revert to the old code or fix the problem in the modified code and then rerun the tests to confirm that things work fine now.
What kind of changes could you make to the existing code? Virtually anything, as long as you can support your changes with the automated tests.
In his book, Fowler prescribes various refactoring techniques. These range from simple -- even trivial -- methods (such as the "Extract Method": extracting some code fragment you can group into a separate method) that don't affect client code to more complex ones that have a more profound impact on code readability and maintainability (such as "Remove Middle Man": if a class is doing too much simple delegation, make the client call the delegate directly) but involve changing the public interface of a class and thereby requiring change in the client code.
Continuous integration
In XP projects, there's no large-scale integration phase at the end of the development activity. You implement some functionality in your code, and integrate it with the rest of the system.
Code integration is an ongoing activity, happening every few hours or at least once a day. In XP development, you have a computer dedicated for integration. When you've implemented some code on your computer (meaning it passes all unit tests), you load your changes on the integration machine along with your unit tests, and run all the tests again. You run not just the tests of the code you're now loading but also all the tests of the entire system again.
Again, because you have an automated test suite, rerunning all the tests isn't a problem. You also get an increasing sense of satisfaction by seeing that your changes work fine with the rest of the system.
If all the tests pass, you can move on to the next programming task on your plate. If even one test fails in any other part of the system, you know your code has caused it to fail, because all the tests were passing before you integrated your code. So, you return the code on the integration machine to the earlier version, go back to your machine, and either scrap and redo your recent work or fix what caused the tests to fail. You then repeat the above process.
As you can see, continuous integration wouldn't be possible without automated test cases. (You can also begin to see why I rate testing as the most important practice of XP. Almost everything in XP works because of this focus on testing.)
On-site customer
XP considers the customer to be an important and integral part of the development team. Yes, a part of the development team. XP recommends that a real customer be available to the development team on a full-time basis for writing user stories (as mentioned earlier, this is the XP term for use cases), providing clarifications as development proceeds, participating in release and iteration planning, writing acceptance tests, etc.
The XP philosophy is that the customer organization should be able to spare one person for the project. After all, the business should get more value from the system than the expense one person not being available. In practice, I doubt if customer participation really occurs this way in most projects, although I have no doubt about the benefits on-site customer participation would have for the development project and eventually on the business value to the customer organization.
The benefits of having an on-site customer are many:
- The customer can set and adjust the priorities in real time based on the assessment of business value, changing business scenario, etc.
- There's no need to have that elusive water-tight requirements document that answers all the questions developers might have as they go ahead with the implementation. Even the most elaborate requirements documents can't anticipate all the questions developers will have as work progresses. However, an on-site customer is always available to provide answers to any clarifications developers need.
- The customer is also available to help make course corrections as clarity emerges about the requirements, their effort estimate, and the consequences.
- The customer participates in the discussions and planning meetings and has a greater understanding of the technical issues as well as the status of the progress.
Pair programming
In my XP seminars, the single XP practice that raises the most eyebrows is pair programming: two programmers working together on one program using one computer. The typical initial response is, "What do you mean by pair programming? Two programmers writing a program together? Are you crazy? That will increase the project cost by 100 percent. How can we do that?"
First of all, pair programming doesn't mean all code is always written by two programmers working together using one computer. Some code is best implemented individually, and some code is best implemented in a pair.
Suppose you're implementing a complex algorithm. Somebody else pairs with you. For some time, you're typing the actual code, while your partner engages in strategic thinking, suggesting better alternatives, correcting your mistakes, identifying unit tests, etc. After some time, you swap the roles.
With this strategy, there's a higher likelihood that you and your partner will identify the right kind of unit tests. There's a higher likelihood that you'll follow the coding standards properly. At least two people now share knowledge about that complex piece of code. In addition, the complexity of the algorithm is likely to be less than if a single developer were handling it.
Pairing in XP is dynamic: No two programmers pair permanently. They keep changing roles and partners. This way, the knowledge about the code is spread even more widely across programmers in the development team.
Pairing isn't just for writing a complex algorithm. It could be for anything -- for example, where one programmer thinks another could help based on that person's familiarity and experience with some requirements or technology. For example, if you have to export some data to a text file, and you know somebody else has done something similar a few days ago, you might benefit by asking that person to pair with you.
At the same time, you shouldn't pair for everything. If a task is simple, you're better off without pairing. For example, if you have to draw a screen layout using an integrated development environment (IDE), you don't need somebody to pair with you for that. If you've written a data export routine recently and have to export some other data in another user story, you don't need somebody to pair with you.
One of the most interesting questions I've been asked in a seminar, by someone who had obviously missed the point about the flexibility of XP, was whether you should always have an even number of programmers in an XP project so that no one's left hanging after all pairs have formed. XP doesn't say you have to write all code in pairs for your project to be an XP project.
Small releases
Instead of aiming for a big-bang release of a software project after six months or a year (or even longer), XP advocates planning for releases in shorter cycles of, say, one or two months.
Shorter release cycles are easy to plan, visualize, and monitor. When you plan for a release after many months, there's a lot of wishful thinking and guesswork about the plan. When you consider what you can release in two months' time, you'll have greater confidence in your estimates and schedules.
Moreover, with changes in business scenarios and system requirements, small releases can help you avoid wasted development effort.
How do you go about scoping small releases? How do small releases work? It works in conjunction with its twin practice, the planning game.
The planning game
Planning in XP projects occurs at various levels: release planning, iteration planning, and daily reviews.
Release planning
Release planning consists of deciding what will go in the next release (due in a month or two). The steps for this are as follows:
- The customer writes user stories describing what the system is supposed to do. These aren't detailed use case specifications or software requirements specification (SRS) documents. Rather, they're short descriptions (a few paragraphs at the most) of what the customer expects the system to do. Customers categorize the stories in terms of business value: Some stories are a must, some are less essential but have significant business value, and some would just be nice to have.
- Developers estimate the time for each story. Wherever needed, they take clarifications from the customer to help them arrive at these estimates. The estimates aren't firm commitments, because the customer's stories aren't firm commitments either; they're only brief descriptions. Developers categorize stories by their confidence in the estimates: Some stories can be estimated precisely, some can be estimated reasonably well, and some can't be estimated at all without more details.
- Customers choose the scope and date of the next release, based on the business value, the time estimates, and the confidence of estimates.
- The developers commit themselves to the scope and date of the release.
If you follow XP strictly, the above steps will happen interactively with the on-site customer and the developers communicating with each other directly.
Iteration planning
A release is broken down to multiple iterations, each one to three weeks in duration (the smaller the better). An iteration isn't a release. It's a planning and execution cycle for a subset of the stories within a release. A release is delivered to the customer, but an iteration isn't. An iteration is a more precise plan for a subset of a release.
The following are the steps for iteration planning:
- At the beginning of each iteration, the customer and the developers together choose the user stories to take up for the iteration. Any user stories from the previous iteration that failed the acceptance tests are also included.
- Developers break down the stories into smaller tasks, each of one, two, or three days.
- Developers sign up for tasks and estimate the ideal number of programming days for each task.
- Developers also set their load factors -- i.e., the percentage of time they'll spend on actual coding (and not other tasks such as helping other programmers by pairing with them, etc.).
- Based on the time estimates and the load factors, developers establish the feasibility of an iteration plan (so many stories in so many weeks for the iteration), or the plan is modified.
Daily stand-up meetings
Every day in the morning, the team gathers for a short stand-up meeting to take stock of the iteration status and to communicate the agenda for the day. The stand-up format of the meeting ensures it doesn't become unnecessarily long. You discuss the work status, important issues, and plans for the day; you solicit pair partners; you get excited about the overall progress you're making (or learn lessons from the failures you've encountered); and then you move on to your day's work.
If there's an on-site customer person, he also joins this meeting. He understand what's going on, chips in when he can provide some clarification or course correction, and makes his own commitments, such as completing acceptance tests, etc.
Metaphor
XP suggests using a metaphor for a project. A metaphor is some term you use to describe the nature of an application, something easy to relate to.
For example, Microsoft uses the term "desktop" for the various items you see on your monitor in the Windows operating systems. Desktop is a metaphor for the operating system. You place various documents on your real desktop, you throw things in a recycle bin, sometimes the recycle bin is emptied, etc. Using the same terms for the appearance and functioning of an interface can help the user understand the design of a system.
However, don't get too hung up on identifying a "eureka"-inducing metaphor for every project. If a simple metaphor comes up naturally in an informal brainstorming session that makes sense and appeals to most people, use it. The benefits of an XP project aren't diluted if you can't think of a metaphor for a project.
Simple design
The fact that I've positioned this practice so late in my discussion of XP doesn't mean it's less important. For that matter, the order in which the other practices appear doesn't reflect on their relative merits. I've ordered them based primarily on how an understanding of one practice helps you understand another one.
One of the core values of XP is simplicity. And nothing reflects this core value better than the importance of starting with a simple design.
When you start work on the first iteration of the first release, do only as much design as you'll need for that iteration. Don't design for user stories you'll add in subsequent iterations (you might never add them). Design for them when you take up those user stories.
Don't design for anticipated requirements or changes in requirements. In addition, don't design for flexibility that will be nice to have in future but isn't required today. Adding flexibility now for future changes may appear smart, but what happens if you never need that flexibility? What if the requirements you anticipate never come up? What happens if you discover a better way of handling that anticipated requirement or flexibility? In all such cases, the design you did based on earlier expectations becomes extra baggage.
In short, XP recommends designing for today's needs today and designing for tomorrow's needs tomorrow. I normally hear a howl of protests at this point in my lectures: "Won't we end up with an unstable system? Won't we end up modifying the same code many times as we move from one iteration to another? Won't it result in a lot of terrible patch work? Will there be any clarity of vision in this approach? How is it any different from the chaos that prevails in many software projects anyway?"
The approach works because of some of the other XP principles. For example, whenever you have to add new functionality or flexibility to existing code, you refactor. And if you have automated test suites, refactoring is simple and safe.
A simple design is, well, simple to understand. It's also simple to extend as additional functionality is added to the system. (It may become large over time, but it doesn't have to lose its simplicity because of that.)
With a simple design, you don't pay (in implementation and testing time) for the features you don't absolutely need. Your design and development is then truly incremental. You don't "complete the design" and then "start the implementation." Rather, you design, implement, test, and integrate. As you have to add more functionality (or existing functionality changes), you design more, implement more, test more, and integrate more.
Collective ownership
In an XP project, nobody owns any code and everybody owns all the code. That means anybody can change any code I've written, and I can change any code somebody else has written.
This normally comes as one of the most shocking XP practices. It's also perhaps the most difficult practice to convince project managers to try, especially when they're accustomed to version control systems. They tend to ask, "Won't collective ownership lead to utter anarchy? How will we trust any code? How will we know that changes made by X to the code written by Y won't break something?"
The simple answer is that if you have unit tests and acceptance tests for the code in place, it won't matter if somebody makes changes to the code you wrote earlier, provided all the tests pass after those changes occur.
If somebody else had written code and you want to add new features to it or refactor it, you can do it because unit tests are in place. If, after you make the changes, the unit tests fail, you can discard your changes. The point is you don't have to wait for the programmer who originally wrote the code.
As a by-product, this practice also spreads the knowledge about the code in the system among all people. You don't have the risk that only one person knows some crucial code in the system. Many people know it, and others can learn about it when needed.
A startlingly successful example of collective ownership in practice, at a large scale, is the WikiWikiWeb site (http://c2.com/cgi/wiki). It's a collaborative Web site where anybody can change the contents of any page. And it works! It's worth a look.
Coding standards
Yawn. Everyone knows there should be coding standards, and everyone knows they're boring. We don't like to curb our individualities, and we follow them only when forced to do so. So, why does XP incorporate coding standards?
First of all, in an XP project, coding standards aren't enforced by someone higher up. The team voluntarily adopts the standards.
Why do developers need coding standards? If you're going to have collective ownership of code, it should be easy to understand the code someone else wrote when you have to modify or refactor it. If there are no coding standards, individual coding styles will make it harder to do that. With uniformly adopted coding standards, anybody else's code should look like your code.
So, at the start of a project, the team decides on which coding standards to follow. XP doesn't tell you what these standards should be, but they typically include things such as the following:
- Naming conventions for classes, objects, methods, variables, etc.
- Placement and use of brackets. For example, "Brackets must begin and end on a new line" or "Brackets must be used even for one-line statements."
- Indentation and tabs. For example, "There should indentation of four spaces; there should be no tabs."
- Comments. For example, "JavaDoc must exist for each method," "Try to keep comments for variables to just one line," or "Have comments on separate lines, rather than at the end of a statement."
- Modification history. For example, "Maintain a list of authors in every file. If you contribute to a file, add your name to the list of authors at the end, with a brief description of changes you made."
Some of the practices I discussed earlier can help you ensure developers don't deviate from coding standards. For example, when you program in pairs and you start to deviate from your team's coding standards, your partner will remind you to follow those standards. In addition, if other programmers are going to see and modify your code (collective ownership), you won't want them to see your non-standard code.
No overtime
In the IT industry, where working late is a way of life, the mention of this XP practice evokes disbelieving smiles on most people's faces. How can you complete your projects on time if you aren't going to work beyond normal hours?
XP strongly recommends that people don't work late hours regularly. When you work late hours often, your productivity goes down, you stop enjoying the work you're doing, and it becomes a chore.
It's alright to work late hours once in a while, even a few days at a stretch when you've slipped somewhere in your work completion. But if you're working late hours on a regular basis, there's something wrong in the project planning and work estimation.
Developers should feel fresh when they come to work in the morning, and feel satisfied with the day's achievements when they go home.
Pradyumn Sharma is a management graduate from the Indian Institute of Management, Ahmedabad (1982-84). He has about 20 years of experience in the IT industry, in various roles such as developer, designer, architect, project manager, trainer, and consultant. He's the CEO of Pragati Software Pvt. Ltd. in Mumbai, India (http://www.pragatisoftware.com). The company focuses primarily on corporate IT training, consulting, and software development business. Pradyumn conducts training programs on object-oriented analysis and desgin, design patterns, and Extreme Programming.
Keyword Tags: Application Development, Business Software, Development, Extreme Programming, IT Strategy, Programming, Tech Architect, Tech Exec, Tech Pro
ADVISORAMA When late morning rolls around and you're feeling a bit out of sorts, don't worry; you're probably just a little eleven o'clockish. -- Pooh's Little Instruction Book
|
ARTICLE INFO
Web Edition: 2004 Week 04, Doc #13571
 FREE ACCESS
|
SUBSCRIPTION STATUSYou are not signed-in. If you are a subscriber to this publication, sign-in above to access locked articles. To subscribe or renew go to www.AdvisorStore.com.
|
 ![]()
Read the advanced guide to creating custom business database solutions with FileMaker software. Subscribe now to gain access to all the archives and downloads.![]()
Learn the fundamentals of using FileMaker Pro software. Every issue gives you step-by-step instructions on creating the databases you need. Subscribe now!![]()
![]()
![]() ![]()
Submit your tips, techniques and advice and let Advisor promote your business and build your career. Show the world what you know!![]() ![]()
|
|