In general there is no “sliver bullet” that will magically improve software development. In fact there is no single development methodology that will magically improve software development. Today the industry is still being plagued by projects that take to long, cost to much, and do not meet customer’s quality expectations. One of the most common ways to try to fix the products being produced it is change the development methodology. At the current time lightweight development process, also known as agile process, are the “in thing”. Before embarking on a process change there should be an exploration phase to show what the possible changes are. That is what this paper is about.

This paper will explain what are some of the benefits of eXtreme Programming, XP, and what are some of the risks of XP. Through out this paper the reader will become more familiar with the strengths and weaknesses of XP. It should be remembered that not all of the aspects of XP have to be implement to make XP work. Also parts of XP can be implemented without committing to all of XP. There are many best practices in XP that should be implemented no matter what the development process is. This paper will help shed light on these issues to help the reader to make a more informed decision of what changes should be made in the current development process.

With any development process there will be affects on the business. eXtreme Programming, XP, is no different than any other development process. It has its affects on the business. Not all of these affects are negative and not all of these affects are positive. What these affects are, and the potential affect on the business, is what this paper will explore. After reading this paper the reader will be better equipped to handle a XP implementation and tuning the process to help benefit the overall business.

XP has some general advantages and some disadvantages. It has been reported that quality improves when XP is implemented, but there are no reasons why (Kolawa). This fact alone should be looked at carefully and should not be the main, or only, driver when considering going to a XP development process. On the other hand if XP is not done with excellent programmers the code generated will lack real internal structure (Kolawa). These two reasons should be enough to make anyone pause to think about all the implications of implementing a XP process.

XP is not the first of its kind of development process. When XP is looked at closely it can be seen that XP has its basic roots in Barry Bohem’s Spiral Development Model. This model was first shown to the world in a paper that Bohem did for IEEE in 1998 (Kemerer). The goal of spiral development is to manage the development process by looking closely at the risks and using the risks factors as drivers for the overall development implementation. The concept of this spiral development has lead the way for many XP like development process known as lightweight development processes. These lightweight processes are also known as agile development processes. XP is the most well known of these agile development processes. Both agile and spiral development processes carry some of their own advantages and disadvantages to the business, but these subjects are outside the scope of this paper.

XP was developed by Kent Beck at Chrysler Comprehensive Compensation, C3, project. Kent was a seasoned development professional that was tried of the same old processes that could not deliver a quality product on time. After a failure to develop the C3 system about 1996, Kent took on the project using his new XP methodology (C3 Team). The project was considered a success and 10,000 monthly paid employees were being served by this system.

There are many aspects of project management that has been included as part of XP. These aspects are very important because of the short iteration in the development process. If XP is being implemented and these aspects are missed, the project will not perform better than any other ad hoc development processes.

The goal of this paper is to give some insight to the advantages and disadvantages, overall, to using a XP development process. There are many books that show how to implement XP and these books should be looked at after the decision has been made to move to a XP development process. This paper is intended to show only the advantages and disadvantages of using XP from the business perspective. It is up to the reader to decide if XP is an option for a particular environment.

Since there are many areas of XP, this paper will address only the areas that give a good overview of the advantages and disadvantages. These areas will cover four of the major aspects of XP. That is: Planning, Design, Coding, and Testing. Of these areas only a small subset of the key areas will be looked at. There are many resources on XP available in books and on the internet, please seek these resources if more information is needed.

Any project needs to have requirements. The way these requirements are gathered change from one development process to another. At the core of XP is the customer. XP works best if there is a customer on site working with the development team. Under the XP methodology if there is no customer on site then there will be an added risk in planning and testing since the customer is vital for these tasks (Beck). When a customer becomes a XP customer there will be some new skills that the customer will have to learn so that the customer can work with the development team in producing the system.

One of these skills that the customer will have to learn is the way requirements are described in XP. In XP a requirement is called a story. A story represents a feature that the customer wants in the software (Beck, Fowler). A story is written with language that the customer can understand and that communicates the functionality to the development team. Because the goal of XP is to have a short development cycles stories need to be kept small. If a story is to large to fit into an iteration the story needs to be broken down so that the smaller parts will fit into an iteration. The major problem, in general with stories, is learning how to define the story so that the development team knows what the story means and the story is clear enough that the development team can have confidence in the estimation of the store. If the story is not clear, the story will have to be reworked until it is clear enough for development to understand and complete the story.This can lead to a very iterative approach to defining stories which could length the project time line.

The next step is knowing when a story is complete. A story is done when the function is demonstrated to the customer and the customer agrees that the function fulfills the expected needs (Beck, Fowler). If a customer has a hard time understanding what they really need it will be a long time until the process gets to the point that the functionality will meet the customer’s expectations.

What XP brings to the requirements table is the user. It does not matter what development methodology is used, if the customer is not completely dictating the requirements the project is going to fail no matter what else happens. To state it clearly, all XP has done is made it clear to the whole team that the customer must be involved intimately with the requirements.

Many of the concepts of spiral development shows through very strongly when the XP ideas of scope and release planning are looked at. By its very nature, spiral development does not have a true concept of a release, unlike the more traditional waterfall types methods. This issue is large enough that every business should understand it before committing to the XP methodology. This issue also brings along may different business consequences that have to be accepted or changes in the XP implementation must be made. These areas are the areas that causes the most friction between development and the business.

XP states that the goal is to build only the infrastructure needed for the current iteration (Beck, Fowler). There are some risks to this hard-line attitude when it comes to software architecture. The risk here is that since there is no formal architecture stages the system architecture, developed under a XP methodology, will not be as flexible. It has been stated that good architecture enables flexible distribution of the system as well as reduce cost of maintenance and evolution (Bredemeyer). In the XP world the idea is that the architecture should change as the needs change. But if there is a major working architecture change down the road it could take some time to get the current system architecture converted to the new architecture, time that could setback the current project timeline.

Under XP, the concept is to put newly developed software into production as it is completed (Beck). This is a problem from the sales and marketing side of the business. It is very hard for press releases to be published on a regular basis not to mention the effectiveness that will be lost by publishing press releases very often. It also becomes a challenge for marketing to target features for certain releases and to go after new business when it is not certain when a feature will be ready to use in a product. Not only do these issues affect sales and marketing, there are some configuration management issues that are made more complex due to these issues. These release problems are magnified with the XP, especially since the basic concept of XP is that release planning happens all the time (Beck, Fowler).

If the system being developed is being developed under a contract for a particular business, XP may require a particular contract type for the project to work. For example, some have said that an “Optional Scope Contract” is the only type of contract that XP can function with, any other type of a contract can be Problem (Case). If a contract is well defined with scope and timeline it would be better to use another development methodology.

It has been documented that some developers believe that software is not a gooey substance that can be shaped, moulded and re-shape as you go along. There is a cost penalty involved to rearchitecting as the project goes (Case). This cost penalty cannot be over looked in any part of the project or the project will have some problems. This is an area that any manager wanting to implemented a XP development process needs to watch so that there are no adverse effects on the business. These hidden costs may not be seen until well after they occurred, or may only be seen after the project’s budget has been compromised.

Since XP does not have a schedule of tasks as normal development methodologies have, tasks are completed without looking into the future so to speak. The assumptions XP makes is that the list of tasks that are important today may not be the same list as next week. This shows again the roots of spiral development, manage risk not tasks. This is a strong concept when it comes to changing teams. When using XP it is not up to the team manager to predict how changes on a team will affect the overall project (Beck, Fowler). The strength here is that projections of when a new team member will become affect are not important because the development process will take into account the new team member’s abilities and development process will continue on uninterrupted.

When looking only at the current “velocity” there may be problems in seeing overall progress being made towards completion. This means that for this velocity to show how much progress is being made towards completion there has to be some strong scoping issues handled in the release and iteration. Without this scoping there is no way to project a completion. Under XP all that is important is “yesterday’s weather” not what is going on at the moment (Beck, Fowler).

The way XP handles project velocity leads to problems if a project needs to know when tasks will be complete. This may cramp a marketing drive for a new version since there will be no way to know when a release will be completed. On the other hand, the built in ability of taking into account spin-up time, or other team changes, can have its advantages.

There have been many project managers that have used stand-up meetings for a long time, this is not a new idea. As the chancellor of the University of Missouri-Columbia made stand-up meetings a key part of life on campus (Missouri). The object of having stand-up meetings is to keep the meeting short and focused on the task at hand. That focus is to keep everyone informed of what is going on everyday. The point here is that XP puts an emphasis on communication and keeping the whole team up to speed with what is going on throughout the project. Stand-up meetings are invaluable for giving everyone an idea of what other people are doing (Beck, Fowler).

There are some rules to these stand-up meetings to keep them effective. The first rule is that these meetings are to be short. To keep these meetings brief make the group stand. This will keep this goal of a short meeting in mind (Beck, Fowler). This focus on a short meeting will also help keep developers focused on the reason for the meeting - giving the status of tasks. It is very important that every member of the team gives a report and that all the other members listen to each report. These reports need to be kept short and simple. This means that each day every person on the team will tell the rest of the team what went on yesterday and what they will be doing today (Beck, Fowler).

One thing that must be kept in mind is that the stand-up meeting is for telling what the current problems are, not trying to solve these problems (Beck, Fowler). The reason of bring up the problems at this time is to see if anyone has already had this problem, or type of problem. If someone has an idea to the solution it should be talked about after the stand-up meeting when only the interested parties are present. By doing this others will not waste time listening to the discussion.

Weather XP is being use or not the concept of stand-up meetings are important for all development groups. It opens communications in many ways and this communication can only be advantageous for the whole business.

Because XP has a strong iterative approach, it should be no surprise that taking time to design the system up front does not exist. XP advocates will state that design should evolve just like the system itself. This will go against the attitude that architecture should not be sacrificed today because of the problems it will lead to tomorrow. The strong argument for architecture is supported by the idea that solid architecture allows for better system maintenance in the future. This idea is supported by many in the industry today. It has been said that XP has a weakness in this area since there is no initial design phase, developers often end up writing code that cannot be extended to meet the needs of the project’s later iterations (Kolawa). But these comments will apply to all Rapid Application Development, RAD, type of methodologies and should not be forgotten for any of them.

Design is always hard for any system. This is due to many factors. Some of these factors could be because what the system is to do has never been done before. This is not uncommon today with all the new and innovative systems being developed. This has also been conceded by XP leaders. The spin these XP leaders put on design is rather different. These leaders say that good design is never easy, but the expression of the strategy should be simple (Beck). Basically these leaders are saying that no matter how hard something is to design, the implementation should always be simple. This can be misleading. No matter how much work is put into design, a complex task will lead to a more complex implementation.

The XP goal here is not as complex as the real problem. In XP the believe is that there should be only the smallest step to get to a payback situation. Another way to phrase it is to make the smallest possible investment in the design before getting payback for it (Beck). This shows that the attitude in XP is everything can be made very simple. Although code can be made to look simple, the process the code must go through may be very complex. This is where it can be seen that XP supporters look at code simplicity as the same as design simplicity, when in reality code simplicity and design simplicity may not always be the same thing. This blur also weakens, not only the argument, but it can also weaken a XP implementation. A manager implementing a XP development process needs to keep this in mind. If a system design has to be reworked there is a high cost in time and money.

Kent Beck has strong roots in object-oriented, OO, development. Most of this is due to the fact that he has a strong background in Smalltalk. With that said it should not be a surprise that XP has strong OO roots. As part of these roots comes the concept of Class-Responsibility-Collaboration, CRC. This is a tool used in part of the development of OO systems.

The object of CRC cards is to help discover the responsibility and fundamental associations of a class (Liberty). CRC cards are used to bring an object/class to life. It allows developers to see how objects interact with each other and the rest of the system. If done right a CRC session is a brainstorming technique that works with scenario walkthroughs to stress-test a design (Cockburn).

CRC cards are just that, they are cards. In most cases CRC cards are 3X5 index cards that are used to write down what an object’s responsibilities and collaborations will be. The small card is to remind that the goal is to keep the number of methods and collaborations down. If an object has a large number of methods it may be a sign to break the object down a little farther. One of the best things about CRC sessions is that all the objects used in the CRC session can become real to the participants. The way these objects become real is by each member of the CRC team walking through the different scenarios and role playing as an object. This role playing will uncover many issues not see before because CRC team members are thinking like the objects.

For a CRC Session to work well there should be some ground rules followed. First of all the CRC session should have a small number of participants, but these participants should be a cross section of the parties with a vested interest in the project. One author has said that there should be no less than three members and no more than five or six participants, which would include one architect, one or two designers, and one or two domain experts (Liberty). In this case the domain experts could be users, but these users would have to be somewhat technical so that they could give good input to the CRC session. The CRC session should also deal will a limited set of scenarios. The goal of the CRC session is to look at a small part of the design, not the whole design. Taking on to big of a picture will make the CRC session to hard to manage. There will be either to many people involved, or there will be so many scenarios that important issues may be over looked.

Overall no matter what the development process is parts of every project could benefit from this type of role playing. This type of role playing can show if there are problems with any of the assumptions that have been made in the project. It will be these assumptions that will cause problems later in the project.

One of the corner stones of XP is the concept of refactoring. Basis for refactoring is to continuously evolve the system design. Since XP is still a RAD style development, it combines the traditional requirements, design, and implementation phases into one phase. This means that the system design must be done in such a way that the design can evolve over time. To accomplish this, the approach to design must be changed from the traditional view. Refactoring is the XP way to change the way design is viewed. One of the thoughts in XP is the system can withstand radical changes of design if the changes can be done in low-risk steps (Beck). The key factor here is low-risk. If the design can not be changed in a low-risk manner, then a more traditional approach to development might be a better choice. This is due to the fact that since the overall architecture is known, in a more traditional approach, a better impact analysis can be done to show other risk areas that may be affected by the change.

If XP is taken in a pure form, then refactoring is done only when the system asks for it. For the system to ask for refactoring there has to be duplicate code (Beck). If refactoring is not handled in a disciplined fashion, then refactoring can lead to “happy hacking” and the project might end up looking like Frankenstein’s monster (Kolawa). If these issues are high risk areas in a development environment, then there should be a set of well defined rules established for when refactoring should be done. There are many guidelines that show some of the rules about when refactoring should be done. One example of these simple rules says comments have to say why something was done not what was done (Hunger).

Kent Beck established a standard for refactoring that is echoed by many XP advocates today (Beck):

On the surface this may sound good, but the next question should be how many of these better ten minute changes will it take to push the current task off schedule? If a developer is free to change any, and all code, that does not look good, how can any time estimates be reliable? It is up to every developer, and development manager, to ensure that timelines do not get compromised to the point of no recovery just for the sake of refactoring. When a task falls behind schedule there is a good chance that the overall timeline will be affected. Falling behind on schedules can lead to missed market windows if not careful.

It is not an uncommon practice to have coding standards in any development environment. There are many reasons, in general, to have coding standards. The risk with coding standards is that they can become overly complex. Coding standards need to be a single easy standard to use (McConnell). By using the a single easy standard, it becomes easy for all developers to know the exact standards and to implement code according to these standards.

Another problem with coding standards is that the standard might be dictated from upper levels. This will lead to the coding standard not being accepted by the development staff (McConnell). The best approach is to show the values of having a coding standard to the development team. Once the development team understands why there should be a coding standard lock them in a room to come up with a coding standard. Once the development team starts creating a standard they will leave the room with only what they believe is an appropriate standard no matter what the length. If the whole team does not see the standard as complete, the team should be left in the room until there is a consensus. Once this consensus is reached it will be easy to enforce a coding standard.

When using XP, the coding standards are an important part of the development culture. One of the main reasons to have documented coding standards, and practice them, is so that the swapping of coding partners is not adversely affected by different coding practices (Beck). This should be an obvious point, if all developers used the same coding standards then moving from one pair to another will allow a smooth transition in coding. There is another reason for coding standards. It will reduce the friction within a pair when the pair is programming and refactoring (Beck). Although some of these issues have been given in the light of pair programming, in non-pair programming these same issues exist. Just look at any developer doing maintenance programming on a project and these same issues will exist, just in a different light.

What all this comes down to is a simple fact: coding standards can not hurt, but they have a great deal of helpful affects. Get them, use them.

Of all the aspects of XP none brings more controversy than pair programming. Many managers look at pair programming as two developers doing the work of one. This attitude is supported by many managers in software development today. It is not uncommon to hear words like development will double expenses and critical manpower for the work being done (Cockburn, Williams). This argument was hard to counter until some of the more recent studies have given enough data to start to prove that it is not the case. Where many supporters of pair programming do fail is in showing that there is a very fine line between productive pair programming and a waste of development resources. These are the areas that all managers need to be aware of so that a development team can operate at its highest levels.

Despite what thoughts may first be conjured up when thinking about pair programming, the data shows some benefits of pair programming. Some of this data is a very compelling argument for pair programming. One study done showed that when a programming pair is first formed there is a “jelling” time for the pair. After this “jelling” time there was only 15% added to the timeline of the tasks being done and that the development cost did not double (Cockburn, Williams). Once this “jelling” time has past, the pair performed only marginally slower compared to a single programmer.

This study also showed that pair programming can improve product quality. Although there not been any business studies on the quality effects of pair programming this study did show some improvements to the product quality. In fact this study shows that there were 15% fewer defects in code produced in pairs (Cockburn, Williams).

Using an example from this study these effects can be summed up: if a system of 50,000 LOC was produced the pair would take 1150 hours compared to single developer of 1000 hours. This is the 15% development time difference. Assume that the single programmer introduced 100 defects per thousand lines of code, this would mean that there would be 1,500 defects in the system for the single programmer. Using the same study data this means that the pair team would have introduced 1,275 - 225 less defects (Cockburn, Williams).

All this said, the data seems to support that pair programming can produce products at higher quality levels only at a 15% cost to the schedule. There is one problem with this scenario, from the business side there are still two programmers being paid to do the job and they are taking 15% longer. How can this be a benefit? There is only one way, it comes with the savings for the fewer number of defects.

In the above study example if it takes 10 hours to fix each defect found, the pair programmers would save 2,250 hours of work at a cost of 150 hours in development. To put it simple a programming pair must have a productivity level of at least 85% of a single programming and defect levels of 15% lower to be beneficial. Any lower productivity levels would be costing much more to produce a product than with a single programmer. A manager overseeing a pair programming team should take measurements of both single and pair developed tasks to ensure that the team has not fell outside this 85% magic number for pair productivity. If the team has fell outside this level, pair programming should be reevaluated because development cost are going to be to high if it continues down the path of lower productivity.

The data presented in this study was done with two programmers. What happens if one member of the pair is not a skilled programmer? It is very easy for a development team to say everything must be pair programmed but happens when there is an odd number of developers on hand? Can a non-trained programmer help achieve the same benefits as two trained programmers? This is an area that this study does not address and to assume there is no additional risks would be an unwise decision. Since the whole goal of the second programmer is to “see the big picture” an untrained programmer would not have this benefit. Because this study relies on this added benefit of quality, this quality benefit may be lost with an untrained programmer. This would lead to a situation where there is more of a lability in pair programming than with single programming. Again to assure that there is a benefit with pair programming, measurements should be taken and monitor due to the risk of a hidden substantial development cost increase.

The one basic concept that has been part of spiral development from the beginning has been the concept of incremental building, or integration. This idea of integration is very fundamental to spiral development so that systems can be assessed before going on to more development. This incremental look at development allows focus to be more on other risk factors which is the basis of spiral development, manage risk not the tasks. With this in mind it is not hard to see why XP has a strong belief that integration should be done often.

There is other data to support the idea of integrating often. As project size increases, construction becomes a smaller part of the total effect of development (McConnell). This can be seen the in following graph:

What can be seen by all the current data is that construction becomes a smaller part of the task, but integration becomes a larger part of the process. So if any risks in integration can be handled early, they should. Under this type of integration process, integration has to become part of the complete process. One way to do this is to write tests and the program in small pieces and combine the small pieces one at a time (McConnell). This is at the heart of integration and integration is at the heart of XP. The basic thought is that if a new problem surfaces during integration, the problem has to be in the new routine that was introduce and this now becomes an obvious problem (McConnell). By doing this, the risks, that are a natural part of integration, has now been reduce, to some degree, because developers have a good idea where to start looking to fix the problem.

How important is this idea of reducing identification time of an issue that has been introduced during the development process? It has been noted that developers can spend as much as 50 percent of their time in debugging. This means that there has to be an effort made to find errors easily (McConnell).

These issues are a problem no matter what development process is used. Leading authors have shown that incremental integration is an advantage to all development projects no matter what the development process is. All XP has done is bring this idea to the foreground as a fundamental idea. Maybe that is where it should have been all along and the industry, as a whole, needs to learn this.

XP has a concept of collective ownership of all code in the system. In short, collective ownership is where anyone can change code anywhere in the system at any time (Beck). Some development organizations, that are not XP environments, have already learned what collective ownership is and have implemented it. A good example of this is an environment where there is a software maintenance team. In this case there is, most likely, already collective ownership of code being practicing. This is because developers that create the code have to transition the code to the maintenance team that will do all the post shipping debugging and limit enhancements. This would seem to point to the fact that in these environments collective ownership is a common sense idea.

But not all development environments have a maintenance team concept. In one cross platform development organization it was reported that because of the multi-platforms it made collective ownership hard (Liu). In this case the organization’s culture just did not fit into collective ownership. Another development manager says: “If this means that anyone can change anything, then we don’t do that. Again, this is a matter of managing limited resources and keeping defects down” (Shelley). In this manager’s mind collective ownership can not be achieved because of the lack of resources and the higher risk of defects. There are some draw backs in XP if there is not collective ownership. It has been described that without collective ownership the rate of evolution of the design slows dramatically (Beck).

There is another method of ownership that has been described and that is of weak code ownership. Under this concept an owner keeps the design but anyone can go in and change the code (FTPOnline). Although this may seem slower, it allows for a true system architect that is needed to hold the whole system together over time and change. The risk here is that if something happens to the system architect there will be problems in this vision if there has been no other staff members prepared to take over. The idea of a system architect is not new and has supported by authors like Frederick Brooks (Brooks).

There is one risk with collective ownership, this risk comes with the confidence that code changes will work all the time. In XP there is only one way to reduce this risk, that is by having complete tests for all of the code. As Kent Beck stated: “Collective ownership is this seemingly crazy idea that anyone can change any piece of code in the system at anytime. Without the tests, you’d simply be dead trying to do this” (Beck). Although collective ownership has been done in some development environments, without tests, collective ownership can only work when each developer does a good impact analysis of all code changes. This approach, of impact analysis, takes very strong and disciplined developers and may not work in all cases. Overall, current supporters of collection ownership think that collective ownership works best when there are unit tests to ensure that there are no side effects to code changes. In this light it can be said that collective ownership can work in for most organizations if they allow enough time to ensure that there are complete tests for the code. If a business can not commit to building these tests, then collective ownership should not be used. The true answer to if a business should move to collective ownership comes down to the answer to a simple question: Will the business be able to take the time to write tests for all the existing code?

One common approach to getting more work done in software development is to use overtime. Overtime has the perception that it is “free” extra time that teams can give to get the job done. The fact of the matter is that the benefits of overtime is exaggerated and the negative impact of overtime is almost never considered (DeMarco, Lister). If overtime is perceived to be “free”, then there will never be a reason to change attitudes towards overtime or its costs. When overtime is perceived to be free a major issue is missed, that issue is that overtime does not really exist. Overtime is always followed by some sort of undertime. Undertime is where team members take work time to other things that could not get done because of the overtime being worked (DeMarco, Lister). This undertime can lead to other issues with productivity that will effect timelines.

There is also another problem that overtime can lead to - turnover. When teams are placed under pressure to work overtime there is a higher level of turnover (DeMarco, Lister). The problem here is the cost to hire and train new team members is high and these factors will affect the overall output of a team. High turnover rates can lead to lower moral of the team which will affect the team’s output was well. It has also been documented that a high level of productivity can not be sustained for much over 40 hours (DeMarco, Lister).

When there is a need to work overtime, there should be a manager looking at why there needs to be overtime. The answer to this question may be very surprising. It may point to the office environment. This may be hard to accept but it may also be the truth. It was once said that anytime there is a need to have team members stay late, or arrive early, or stay home to get work done, the problem is the office environment (DeMarco, Lister).

Other reasons to have teams work overtime may have nothing to do with getting the project complete. It may be strictly political. Overtime may not be needed so much to get the work done, but to be shield from blame when the work does not get done on time (DeMarco, Lister). These types of political moves are very apparent to team members and a manager that makes this type of move will lose credibility with the team they lead.

Under XP the goal is not to work more than a 40-hour week because a 40-hour week allows for fresh and creative work. The words: “To meet our goals, we’ll have to work late again” actually says that the project is already in trouble and long hours will not solve the problem (Beck). Since there are already many factors pointing to the problems of overtime, XP goals of no overtime is only to help improve the quality of the software being developed and it follows the advice of may authors to help improve productivity and reduce turnover.

Testing is a key component of XP. This is one of the majors strengths of XP. In fact XP brings the old saying “quality can not be tested in, it has to be built in” to new heights. If the software industry had actually built quality into systems from the beginning there would be no push back from users over systems that do not stay running and have other quality related issues. On the other hand XP does not bring many new ideas to testing. For the most part XP brings some time tested and industry recognized ideas about testing to the forefront as fundamental processes in the methodology.

At the base of the testing concepts of XP is the unit test. Unit tests are not a new concept in the industry. Unit tests have be identified and talked about for a long time in the industry. Robert Glass gave a simple definition of a unit test in the early 90’s. This definition was: individual small program components are tested at the unit test level before being assembled into the software as a whole (Glass). The accepted practice today is that unit tests are testing the lowest levels all the way down to the object or function/method level. Although it has been documented that unit tests are effective they are also extremely time-consuming and labor-intensive (Johnson). XP takes some of the sting out of unit tests. The way this is done is by having the developers instead of writing testing code and throwing it way, write the test code and keep it as part of the permanent automated test suite.

Testing has become such an issue to system development that there have been many authors that has argued the idea of “Always test your code, even if that means your schedule will slip” (Maguire). Since XP makes units tests so fundamental to system development, it allows the reduction of risk to slipping the schedule because these tests are written and run all the time.

As good as this has sounded, there could be one problem with the unit tests in XP. This problem comes from a statement that Kent Beck made that could be misinterpreted:

The problem with this statement is that it is possible that developers could use this as an excused not to have unit tests for all the code. One way to reduce this risk is to use branch coverage analysis tools to ensure that the code not being tested falls within Kent Beck’s statement. If the wrong code is not tested there will be a weakness in the system that will show itself at the worst possible time.

A final XP thought about unit tests. Under XP besides being automated, unit tests need to be a black and white view of the current state of the system being developed. The way this is achieved is to have the unit test be automatic at giving an unqualified thumbs up or thumbs down indicator (Beck). If the test returns this thumbs up or thumbs down indicator, a quick and simple glance at the test results will show the state of the system and not take a lot of time to interpret the results.

It does not matter weather XP is implemented or not, this aspect can go a long way to ensure a constant working state of the code being developed. This is invaluable no matter what the development process is.

XP has something going for it that many development methodologies do not. A strong commitment to quality of the product being produced. This is very appealing to developers and managers that have been through the “good enough” battles for so long that they now know this “good enough” war is no more than a losing war and things have to change. One way that XP shows this commitment to improved quality is by the idea that since there are already unit tests these test must run all the time with no exceptions. Founders of XP believe that running tests are a high enough priority that the whole team should drop what they are doing to fix a test that has broke because the amount of work to fix the test is unknown and it maybe anywhere from a short period of time to a very long time (Beck). In practice this is not the case. But at least part of the team works to get the test running. In general this can be found quickly for no other reason than the short integration cycles, it keeps the number of changes down so the team has a good idea of where to start looking.

This needs to be the attitude if for no other reason than the lack of an impact analysis of code changes. If failing tests are not fixed the stability of the system is in question. A side effect to this dropping to fix broken tests is that some current tasks may fall behind schedule. If tests start to break on a regular basis then the tests quality needs to be addressed. If the unit tests are taken seriously the whole development team can have confidence that the system is reasonably stable.

Test First Programming, TFP, is the strongest element of XP. The idea behind this concept is simple, TFP programming is to write the tests before writing the code. At the current time there are no studies that show the quantitative impacts of TFP, but there has been a lot of information that has been written by many different practitioners that show the benefits of TFP in various real world projects. When looking at this information it can be reasonably seen that overall practitioners see great benefits from TFP.

To help understand some of the benefits of FTP there needs to be an understand of the term coupling. Coupling is defined as the relationship between objects and/or functions/methods to each other. Steve McConnell put it best:

he reason that coupling is important is that TFP can only work if objects are developed in such ways as to allow the object to stand on its own. If objects are tightly coupled then TFP will be very hard, or impossible. So what TFP does is it forces the developer to design the class to be loosely coupled and testable (STQE Bedunah). It has been long accepted practice to keep things as loosely coupled so that maintenance work can be done with lower risk of side effects.

When using TFP it is important to remember that these unit tests will be run all the time. If TFP is implemented right these tests will become a regression suite for the system being developed. As noted by one author “tests have to be simple to run and they have to run fast. Tests can not be run every minute or so if they take half an hour to complete” (STQE Thomas). By this comment it becomes obvious that these tests are run all the time. In fact most TFP supports advocate the position of change one thing run the tests, fix any that break, then go to the next task.

It is important to note that TFP must become part of how the development staff works all the time. This is not something that can be done once in a while. TFP has to be committed to for all work if the true benefits are to be realized. There is also another benefit to TFP programming that comes along for free. These tests that are being written will actually help to define the application that is being developed (STQE Thomas).

TFP programming has done a lot to improve the quality of the system being produced. Had the software industry learned this lesson a long time ago it is possible that today there would be no jokes of “if cars were built like software...”.

There is no “sliver bullet” in software development. This is a fact that has to be accepted because it will not change, at least in the near future. The first step to improving software being developed is the simple fact - hire the best. Tools and processes have little effect on top developers and poor developers tools will not help much. Edward Yourdon put it best:

XP is more effective if there are good developers to start with. Most of this has to do with the smaller teams that XP uses and the closeness with which the team works. Even inexperienced developers can do a lot in XP if they have the ability and drive to learn new ways to think.

What XP brings to the table is simple, in many areas XP brings best practices to the forefront of development. There are few areas of XP that are new due to XP. Most of the XP practices are what has been determined good practices over many years of work in the industry. The fact that XP places such an emphasis on the customer being involved should not be taken lightly. This is a practice that should have been done a long time ago to ensure the customer is getting the system they want.

Due to XP roots in spiral development there are some risks for deployment that have to be address. If these issues are not address there will be issues when it comes to updating and maintaining the system. The first of these issues is Software Configuration Management, SCM. This is not just a problem to XP but to development in general. There has to be controls over what is placed at a customer site and how to reproduce that environment no matter what. This is a high risk item that is not looked at until there is a major problem and then it is to late. Because scope and releases are not done in a traditional matter there could be higher hidden costs with scope creep. This can be handled in the XP planning game if the release and scope issues are handled during planning.

Project velocity does a great job at taking into account the changes naturally, but this is a risk area if tasks have a hard delivery date. If there is a hard delivery date this area needs to be watched closely to ensure the date can be met. One of the largest problems in development can be communication. This is why XP places so much on communication. Ideas like stand-up meetings are to keep everyone informed and accountable for what is going on and they are just good no matter what development process is used.

XP supporters tend to talk about design simplicity as meaning both code design and system architecture. Care should be taken when architecture is looked at only in short term. There will be cases in the future that some architecture changes will become very large since architecture is not design for long term. No matter what, architecture changes have larger impact than any code changes so be careful in these areas. Keep in mind that these simple design risks are due to the fact that XP has a spiral development process at it roots.

The XP concept of refactor mercilessly can have its risks. If developers just refactor every time code is being edited it can lead to the scenario of refactoring for two days then code for one on a task that was estimated to be a one day task. If this is done enough the whole project could find itself behind by a month or more. Although there are good benefits to refactoring make sure that developers are held accountable for tasks constantly falling behind schedule because of refactoring. Refactoring at the expense of an estimate will have consequences somewhere down the road.

Data shows that pair programming has benefits, in reality that window is very small. When using pair programming care should be taken to ensure that there is a return for the investment. Collective ownership reduces risks when there is staff loss. This reduction in risk is good for all businesses.

XP show a commitment to developing a high quality product. This should not be over looked as one of the strengths of XP. This has needed to be done in the industry for a very long time. This commitment is shown in all of the concepts in testing. These testing ideas should be applied to all development groups no matter what the development methodology is. As XP has founded and supported testing will only improve a product. Of all the testing concepts test first programming is the best idea this industry has had in a long time.

In short there are many good aspects to XP. These aspects have encompassed what has become best practices in the industry. Other aspects are higher risk and should be monitor for a return, if implemented. Just like any other methodology, XP does not have to be taken as a whole to work. If the risks are to high for some aspects of XP to be implemented, then implement other aspects. There are enough good practices in XP that every development group should find something to help improve development time, costs, and quality.

Kolawa, Adam - The ABCs of XP, RAD, and PSP [Online]. Available: http://www.stickyminds.com/queng.asp?Function=FEATURECOLUMN&ObjectId=3411&ObjectType=ARTCOL&btntopic=artcol

Hunger, Michael - When its Necessary to Refactor [Online]. Available: http://emw.inf.tu-dresden.de/de/pdai/Forschung/refactoring/refactoring_html/node26.html

Case - The Case Against Extreme Programming: Release Plan Optimism [Online]. Available: http://www.softwarereality.com/lifecycle/xp/contracts_in_xp.jsp

C3 Team - Chrysler Goes to “Extremes” [Online]. Available: http://www.xprogramming.com/publications/dc9810cs.pdf

Missouri - MU Across the Nation [Online]. Available: http://www.missouri.edu/~news/chancellor/cu1298.html

Bredemeyer - Motivating Software Architecture or Why Do We Need Software Architecture? [Online]. Available: http://www.bredemeyer.com/why.htm

Cockburn Alistair - Using CRC Cards [Online]. Available: http://members.aol.com/humansandt/techniques/crc.htm

Liu, Yuanxin - Individual Report for COMP290-079 [Online]. Available: www.cs.unc.edu/~liuy/classes/comp290_XP/report.doc

Shelley, Clifford - Our Collision with XP: What We Picked Up [Online]. Available: http://www.computer.org/SEweb/Dynabook/ShelleyCom.htm

FTPOnline - Where Does Refactoring Fit In? [Online]. Available: http://www.fawcette.com/resources/managingdev/interviews/fowler/part4/

Cockburn, Alistair and Williams, Laurie - The Costs and Benefits of Pair Programming [Online]. Available: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

STQE (January / February 2002). Bedunah, Jason - Introducing Test-First Development.

STQE (January / February 2002). Thomas, Dave and Hunt, Andy - Learn to Love Unit Testing.