¶ … Programming: Rapid Development for Web-Based Applications" by Frank Maurer and Sebastian Martel of the University of Calgary and is composed of an in-depth explanation of extreme programming (xp). The bulk of the content of the article describes the advantages and benefits of this method. One of the most immediate benefits of extreme programming is that it changes the way that work and communication can manifest in the world of programming: it makes it a more social and team-oriented form of work which is a tremendous advantage. This essentially means that work can be conducted in a more pleasant manner, which means that members of staff will enjoy doing it more, something which will ultimately lead to greater productivity. For example, as the article aptly states, "XP's focus on small teams lets it replace paper-based documentation with face-to-face communication. Hence, it's a good fit for many Web-based software projects, which often postpone documentation efforts because of time-to-market constraints" (Maurer & Martel, 2002). This is no small advantage: companies all around the world and in every field try to find effective, lasting ways to reduce paperwork and to make work more enjoyable and efficient to complete. As another expect aptly summarizes, "For developers, XP allows you to focus on coding and avoid needless paperwork and meetings. It provides a more social atmosphere, more opportunities to learn new skills, and a chance to go home at a decent time each night. It gives you very frequent feelings of achievement, and generally allows you to produce code that you feel good about" (Smith, 2003). This statement very succinctly describes an overt benefit of this type of coding process, one which the article in question clearly supports: it makes the task of coding more meaningful -- which indicates that programmer will be able to do better work and achieve more lasting and meaningful achievements and innovations.

Many experts in the field praise XP for how it pushes communication and adaptability to the forefront: "the team gets enough feedback to see where they are and to adapt the practices to their unique situation" (enterpriseblog.net, 2009). However, one of the benefits of the Maurer & Martel article is that it doesn't shy away from highlighting the flip side of that aspect. This aspect of extreme programming has an expiration date; it doesn't grow and evolve with the company as the company grows and evolves. As Maurer and Martel point out, "As the development organization grows, however, time spent exchanging product knowledge and training new people increases and often renders XP unsuitable" (2002). This means that there's a point when the method will become obsolete or unusable. The authors of the article have no problem pointing out how there is only a finite time that this type of methodology is useable; that it's simply unable to develop and flourish with the changing needs of the programmer and corresponding company.

However, the article fails to go truly in-depth into some of the more immediate problems that can arise when implementing XP. Xp poses some very unavoidable and very immediate problems that make it unsuitable for a range of organizations, merely as a result of certain logistic issues. " Its attraction is that it puts developers in control of the development process. That's a 'fantastic win,' says software consultant Pete McBreen, author of Questioning Extreme Programming (Addison-Wesley). 'The problem is that you need an entrepreneurial, agile, or custom organization that can make decisions quickly,' says McBreen. 'That's where problems surface. The XP concept rests on the premise of the whole team being in one place so it can quickly answer developers' questions.' Getting answers from a middle manager about a project's requirements can keep everyone waiting, says McBreen" (Weinstein, 2002). Thus, this demonstrates that because Xp is such a highly communicative process -- a process which essentially relies on communication, it's going to be held...

Furthermore, the Maurer and Martel article failed to mention that there is still a strong learning curve when it comes to adequately implementing XP: "Not everyone out there is an XP process expert. Not everyone has time to read all 20 XP books, scour the XP newsgroups for vital information not contained in the 20 books, and so on. Not every team will have access to an eXPert Coach (either full or part-time). In other words, the amount of hype that surrounds XP is not matched by the requisite skill-set needed to successfully execute an XP project. I suspect that the result (as XP's promises entice more and more teams) will inevitably be confusion, and a dirty underbelly of (mostly unreported) failed attempts at XP" (Stephens, 2003). Thus, as much teamwork and unity that XP does require, there is still the potential for rampant miscommunication and the dire need for an XP expert on site, without which, the organization can suffer.
These are very real concerns; concerns that the Maurer and Martel article simply don't elaborate on fully enough. Rather, there's evidence of that article skimming over such issues completely: "XP employs various practices to keep software quality high. Although some might appear unusual, their combined effects ensure that the team maintains high quality without slowing down the development process" (Maurer & Martel, 2002). There's simply not enough evidence presented in the article of how the XP process can keep software quality high when the learning and mastery curve of this particular methodology is also high. While XP does have a great amount of potential, the authors of the article do need to verbalize more acknowledgements as to how various issues and conflicts with XP should be treated and what the best tactical strategy is.

On the other hand, one of the massive benefits of XP is well highlighted in the Maurer and Martel article: this advantage revolves around the commitment to simplicity that XP has no problem in making. Simplicity makes the work of designing software and utilizing software so much more compelling for groups both outside of and inside of the programming world. "In XP, the best software design runs all the test drivers, has no code redundancies, has the fewest possible classes and methods, and is easy to understand. XP does not invest in up-front analysis and design. It trades the potential savings of anticipating change against that of wrongly guessing the system's future direction" (Maurer & Martel, 2002). This statement alone demonstrates the vision and commitment to a highly useable system that the developers of XP have manufactured. As other experts have explained, elements of the XP system designate simplicity of design as running all the tests, revealing all intention, lacking duplication, and offering the least number of classes or methods (Fowler, 2004). This is absolutely no small feat. As Maurer and Martel describe, XP is opening the door to a system where its simplicity makes it more accessible to more people; the article excels in the sense that it is able to highlight this dynamic rather aptly, as it's something which deserve a great deal of attention and note.

Finally, the article excels in that it efficiently addresses one of the more famous benefits of XP which is that it require pair programming. The authors highlight some of the more obvious benefits of pair programming: that it forces people to treat a goal or endeavor with two sets of eyes and brainstorming capabilities. However, Maurer and Martel are able to succinctly address some of the more overt criticisms people have with pair programming and explain why these concerns aren't legitimate. "Managers often object to pair programming on the grounds that it doubles a project's programming costs. However, in their controlled experiment measuring pair-programming overhead, Williams and colleagues found that it takes only approximately 15% more effort than solo programming, but increases both software…