Information Development Trends of Extreme Programming - Essay Example

Information Development Trends Extreme Programming Advantages and Disadvantages I- Introduction For many years, building an application is significantly time consuming and predominantly disorganized. The "code and fix" practices and bureaucratic development approach of software development teams are more often resulting to long integration phase and numerous defects. Software development fails to deliver value and this failure has a large economic and human impact. Extreme Programming promises a new beginning for software development. It is a methodology of short development cycles and small release, and believed to be code oriented and lightweight well matched for small development projects. It is seeking to improve the quality of software by solving the key problems in software developments. However, the radical nature of Extreme Programming seems to be causing cultural and developmental conflicts within the software development community. This paper will discuss the fundamental problems of software development and the advantage and disadvantages of adopting Extreme Programming II- The Fundamental Problem Risk is the foremost predicament of software development. Schedule slips, project cancelled, system fails in a couple years, software defect rate too high, software created didn't matched the business needs, software features that do not have any business value, and development staff sudden turnovers (Beck 2000)1. There is a lot to learn from experiences and these predicaments have been affecting software development economically for many years. Hierarchal software development methodologies seem to work against software development since it cannot deliver the value. Schedule slips as developers have to go through a series of bureaucratic steps and sequential pre-requisites. Consequently, after several delays, project is terminated before even reaching production. In another distressing situation, even if the software managed to reach production, defect rate rises to a great extent that the system must be replaced just after few years of use. Included in the list of production related dilemma is the worthlessness of the system to solve the business problem that was originally posed, simply because the business problem was misunderstood from the very beginning of the development. Another one, actually caused by recurring schedule slips, is the unsuitability of the system to the current situation of the business. This is for the reason that the problem it was designed to resolve many months ago is replaced by a more complicated business problem. Finally, after a few years of endless program patch and modification, programmers start to disgust the program, pack their bags and leave. These predicaments cost a great deal of insecurity to the industry and solving these problems might bring back software to development to life. In late 1990's, a new breed of 1Beck Kent, 2000, "Extreme Programming Explained", Addison-Wesley, United States of America, ISBN: 201-61641-6 software development methodology was born as a solution to the chaotic and bureaucratic development, the Lean Software Development with the Agile family of processes and Extreme Programming (Windholtz 2005)2. III- Extreme Programming Extreme Programming or XP, is a member of the Agile family of processes, which is part of the Lean Software Development. Each process in the Agile family has its own guidelines for how to structure and complete programming work ( Fig. 1). XP is about delivering to deadline, deploying programs to production in just a matter of weeks (Windholtz 2005)3. XP is an efficient, lightweight, low-risk, flexible, and enjoyable way to develop software. It is designed to work with projects than can be develop by smaller teams with a maximum of ten programmers. Projects that is free from the limitation of the existing computing environment, and small enough to do a test within a few hours of the day. XP is new but the ideas behind it are old and conservative. It is in fact a collection of proven ideas and implementation strategies over decades of software development, joining them 2-3Windholtz Mark, 2005, "Lean, Agile, and Extreme Programming", Object Wind Software Ltd. in the RailStudio.com altogether in one methodology. XP is designed to ensure that these practices are followed thoroughly and each practices support each other to the greatest extent possible (Windholtz 2005)4. a. The Practice - Extreme Programming converge the entire team on delivery of value and reduction waste. On a regular day, team members will have a quick 15 minute stand-up meeting, get a story from the task board, pair-up, consult customer sitting with the team, hold programming episodes, monitor automated build and test system, and deliver a few fully tested integrated business stories. In XP, the term "stories" means the most valuable features from all possible business features measured by cost and speed of the team doing the feature (Windholtz 2005)5 , (Chromatic 2003)6. b. XP Episode Cycle -The XP's Episode cycle (Fig. 3) begins with consulting the user regarding the task. Then the pair-up programmers will write an automated test for the particular task. This will normally takes about ten minutes of their time until the test fails. They will now join forces to write the code in 15 minutes max, using fewer lines of instructions as possible to make the test succeed. After a successful test, and within 15 minutes, they will clean up the codes and add better design structure to it. Finally, they will submit their code to the source code control to check its integration capability. If integration becomes problematic, they will just disregard the code and do the cycle again instead of wasting their time trying to solve a difficult integration (Windholtz 2005)7. 4, 5, & 7 Windholtz Mark, 2005, "Lean, Agile, and Extreme Programming", Object Wind Software Ltd. in the RailStudio.com 6Chromatic, 2003, "Extreme Programming Pocket Guide", Team-Based Software Development, O'Reilly-2003 XP's sets of values encourages positive working attitude such as communication, simplicity, feedback, courage, and respect. It is a logical software development process exploiting reduction of cost in software replacement by doing work a little at a time instead of spending too much time planning, analyzing, and designing for the far-away future (Beck 1999)8. IV- Extreme Programming Advantage XP differs from other software development methodologies in many ways. For instance, it uses short cycles instead of traditional and time-consuming long cycles. Its planning approach is incremental thus able to react to the changing business requirements flexibly. It allows programmers and customers to monitor the progress of development and detect defects early through its automated test approach. More importantly, its evolutionary design process that last longer than other methodologies. XP greatly enhances close collaboration in all level of programming skills and promote practices that work with the quick-fix instincts of programmers and the lasting concern of the project (Beck 1999)9. The XP's unique set values were put together to guide the programmers to work in the best interest of the project instead of their own short-term instincts, since short-term objectives often disagrees with long-term social goals. a. Communication is essential since most failures of the project emanates from not talking to each other about important issues of the project. For instance, programmers sometimes does not inform colleague about critical design changes or for some reason does not ask customer the precise question. 8-9 -Beck Kent, 1999, "Embracing Change with Extreme Programming", Cover Feature, First Class Software, October 1999 Miscommunication in software development is real and does not happen by accident. XP's objective is to keep the right communication channels open at all times and ensure the smooth flow of communication by employing several communication dependent practices that cannot be ignore by anyone. Unit testing, pair programming, and task estimation are examples of those practices that encourages compulsory communication between programmers and customers. However, this does not mean people cannot make mistakes or get distracted. XP is just making sure that this would not happen regularly (Beck 2000)10. b. Simplicity comes next with the aim to promote the creation of the "simple things that could possibly work". Simplicity is the opposite of looking ahead in the future, which is definitely not easy to implement. People by nature tend to look ahead and worries about tomorrow. What will be next What is out there However, instinctively thinking ahead is listening to your own fears. As Beck (1999)11 explains, simplicity means, "do not try to solve problems you don't have". XP is relying on a principle that it is better to do simple things now and change it only when the need arises, instead of spending so much time building a complicated thing that may never be used. In addition, there is a mutual benefit between communication and simplicity because the more you communicate, the better you understand the things to be done and the more you are conscious about the things that you should not do. 10-11Beck Kent, 2000, "Extreme Programming Explained", Addison-Wesley, United States of America, ISBN: 201-61641-6 Furthermore, it is easier to communicate when the system is simple, as it requires fewer programmers (Beck 2000)12. c. Feedback - Optimism in a programming environment is an occupational hazard and feedback is the treatment of such kind of threat. Specific feedback regarding the present condition of the system is invaluable. It works in a diverse time scales, minutes, hours, and days. Programmers have a minute-by-minute feedback regarding the current circumstances of the system. He can immediately check and estimate when a customer write new stories and send a concrete feedback to the customer about the status of their stories. The person in-charge in monitoring the progress of the tasks to its completion will later give his overall feedback to the team; this will give a complete picture of everything they planned to do in a specific period (Beck 2000)13. The primary strategy of the XP process is to prioritize the most valuable stories and put them in production as early as possible. Feedbacks from production will then give programmers an idea about the quality of decisions they made and learn from them. Other methodologies do not offer the same benefit since most of the programmers involve in the project will never see the system in production, and therefore ignorant of the quality of systems they created. This makes XP planning strategy the exact opposite of other strategies, which are normally keeping the system longer in development because of the prevalent belief that they can no longer make interesting changes when the system is already in production. 12-13 -Beck Kent, 2000, "Extreme Programming Explained", Addison-Wesley, United States of America, ISBN: 201-61641-6 Feedback, communication, and simplicity work together in harmony and assist each other during development. The more feedback, the easier to communicate, and the more you communicate the simpler the system (Beck 2000)14. d. Courage in XP represents the ability of a development staff to make concrete decisions. Throwing or tossing away a code (see Fig. 3) or a day's work takes courage. XP encourages programmers to assess their codes usability, if a code is out of control then better toss it away and start again. It is better to start from scratch but clean and simple instead of persistently debug the code. This is a design strategy similar to a hill-climbing algorithm. However, the problem with this algorithm is reaching local optima, since only large change can improve the circumstances. It is important to have the three values in place for courage to work otherwise it would be just plain "hacking" (Beck 2000)15. Courage works with communication because it allows the prospect of a high-risk, high reward test. Simplicity invites courage because you will have more courage dealing with a simpler system than a large and terrifying complex one. Concrete feedback adds more courage as you will feel safer knowing the truth and will try drastic changes whenever possible (Beck 2000)16. V- Solving the Fundamental Problems with XP Now we know all the values and practices of XP, how it will address the fundamental problem of software development a. Schedule Slips -XP promotes short release cycles, one to two months of development, therefore the possibility of any schedule slips is small. 14-16 Beck Kent, 2000, "Extreme Programming Explained", Addison-Wesley, United States of America, ISBN: 201-61641-6 When a customer requested a feature, it will only take one to four weeks iteration and within that period, XP is planning 1 to 3 days tasks to enable the team to resolve problems even during iteration. Finally, it will implement the highest-priority features first, so any feature that slips earlier before the release will be of lesser importance. b. Project cancellation is unlikely to happen since the customer will be ask to choose the smallest release that they feel make the most business sense. This way the chances of cancellation before the systems reach production is less. c. System goes sour - XP's comprehensive suite of tests ensures a quality and stable baseline. To keep the system from going sour, the suite is run and re-run repeatedly after every change of feature, keeping the system in top shape at all times. d. Defect Rate - There is absolutely no defect rate since tests are being done from the viewpoint of both programmers and customers writing the test feature by feature. e. Business Misunderstood -Business is always understood because customers are integral part of the team and by procedure; specification is constantly polished during development. Therefore, the software is not just a product of the team but by the joint effort of both. f. Business Change - XP's short release cycle approach minimizes business change during development of a single release. In addition, during the release, customer is allowed to substitute new functionality in place of incomplete features. g. False Rich feature- There is absolutely no false feature rich since XP only addresses high priority tasks. h. Staff turnover is unlikely to occur because XP supports programmers all the way, letting them decide and do their responsibility for estimating and completing their work. Support them with feedback about the actual duration of the work they finished so they can improve further. There is no reason to frustrate since no one will ask a programmer to do the impossible. The rules of XP are clear on who can make and change estimates. Team members are always in contact so there is no loneliness and finally, new team members are assisted and encourage to accepting responsibility progressively. VI- Extreme Programming Disadvantage Although learning and following the practices of XP is easy and open to anyone, putting the pieces together while keeping them in balance seems problematic. The pieces have a propensity to support one another but in the actual implementation, real problems will also occur such as fears, concerns, mistakes, and events that can throw the process off balance. Keeping them in balance will require a coach, probably a senior programmer, but this is not a guarantee that it will remain stable through the end of the project. Adopting XP maybe a little difficult for programmers doing the opposite all their life. The challenge here is not the programming but the change in the value system. People value challenges at work, we are proud we accomplished things particularly those involving complicated problems. In XP, you have to learn to hate complexities and see the world it its simplest form because XP is an environment built in the principle that "you can develop only as fast as you learn" (Beck 2000)17. Collaboration is difficult since you have to learn other people skills and interact as closely as possible with your team. You must learn to forget the values of individual thinking and achievement and try to be always dependent on feedbacks. XP relies on smooth expression of emotions, and sudden frustration within the team will surely degrade performance severely. The biggest problem according to Beck (2000)18 is business culture. For instance, customers will normally insists on a complete specification, design, or whatever they can think about that would help to make their decision. On the other side, programmers will also insist on priority features approach since this is the primary principle of XP. The difference will then create an argument and the collision between the customer and the team's unbending culture will occur. Another culture related problem is the fact that XP's high speed but convenient timing tradition will not fit a company that require long hours of work just to prove an employee's worth. XP is not ideal for developers using a technology with an inherently exponential cost curve. For instance, you want to develop a Nth mainframe system that requires the same relational database but you are not sure if the database schema is precisely what you need, then XP is not for you. Modifying hundreds of existing application is not "code clean and simple", and it will only make things worst and complicated, and very soon you will lose the XP flexibility (Beck 2000)19. Another obstacle in XP implementation is an environment that is not used to a minute-by-minute feedback. 17-19 -Beck Kent, 2000, "Extreme Programming Explained", Addison-Wesley, United States of America, ISBN: 201-61641-6 For instance, if a system requires more than eight hours to compile and link then you cannot build, integrate, and test a number of times a day. In addition, putting a system in production only after a two months quality assurance cycle is not XP way, and more importantly, you will not be familiar with the quality of you system. In general, Extreme Programming is hard to do. Many developers are reluctant to adopt the practice since it will take more than just a simple implementation. It needs huge amount of discipline to get it done. The idea that customers must be constantly involved in the development process is scary for people who already have too much responsibility in their hands. Typical customers are more confident seeing a detailed plan that gives them the impression of accuracy and professionalism. XP is limited to project size and type constraints. It cannot scale up to large projects, as it does not have adequate architecture planning and perhaps over confident on fast results. Economically, pair programming means double compensation, and keeping the team in the balance requires additional supervisory staff. In addition, the lack of specific requirements at the start of the project cannot guarantee customer satisfaction at the end. Some managers view XP as unpredictable and risky because it seems to disregard the importance of planning and control. Lastly, XP is noted for ignoring the value of documentation and it is only applicable to experienced developers (Fhruling et. al. 2005)20 20-Fruhling Tyser and Vreede, 2005, "Experiences with Extreme Programming", University of Nebraska at Omaha, College of Information Science and Technology, Proceedings of the 38th Hawaii International Conference on System Sciences - 2005, 0-7695-2268-8/05/ VII- Conclusion Extreme Programming is a promising software development methodology with features undeniably significant to solve the fundamental predicaments of the software the development community. Developer and customer integration is a good initiative and reducing the development cycle is economical and risk free. Furthermore, Extreme Programming upholds the value of communication, simplicity, feedback, and courage, initiating a disciplined software development environment. However, in the real world, Extreme Programming practices and culture seems to divert the natural flow of things to the opposite direction and it is not applicable in many circumstances. These diversities oppose and seem to disregard many proven principles and techniques such as design, planning, control, documentation, and more. The culture of Extreme Programming is also a major obstacle as it complicates our society's acceptable norm. This is just a few of the many reasons why many developers and managers are hesitating to adopt this methodology. Finally, experience can teach us more but try it at your own risk. VIII- References Beck Kent, 1999, "Embracing Change with Extreme Programming", Cover Feature, First Class Software, October 1999 Beck Kent, 2000, "Extreme Programming Explained", Addison-Wesley, United States of America, ISBN: 201-61641-6 Chromatic, 2003, "Extreme Programming Pocket Guide", Team-Based Software Development, O'Reilly-2003 Fruhling Tyser and Vreede, 2005, "Experiences with Extreme Programming", University of Nebraska at Omaha, College of Information Science and Technology, Proceedings of the 38th Hawaii International Conference on System Sciences - 2005, 0-7695-2268-8/05/ (C) 2005 IEEE Windholtz Mark, 2005, "Lean, Agile, and Extreme Programming", Object Wind Software Ltd. in the RailStudio.com Further Readings: Kicker Michael, 2001, "eXtreme Programming in Open-Source and Distributed Environments", Siemens AG, Corporate Technology Rumpee Bernhard and Scholz Peter, 2003, "Scaling The Management Of Extreme Programming Projects", Special Issue on Management of Extreme Programming Projects, Vol. III (8), pp. 11-18. ICFAI Press, Hyderabat, August 2003 Read More