Communication With Project Developers During The Coding example essay topic

Kent Beck introduced extreme programming to the programming community. He developed and documented an approach to computer software creation that uses elements of traditional methods and redefines the priority, sequence, and emphasis of these elements to increase the number of options available to developers as they fashion new software he calls Beck's Extreme programming (Beck, 1999). To put it in layman's term Extreme programming takes a few of the more important aspects of software development to the extreme, and de-emphasizes the sequence of events that are followed in the traditional programming environment. What is Extreme Programming? Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

Before Extreme Programming, programmers worked long hours, typically 50, 60, or 70 hours a week in other to meet an unrealistic deadline and quickly become burned out (Ambler, 2002). When projects run into trouble, often before they " ve even started, programmers point fingers at others. The main idea behind XP is to introduce software that is easy to maintain and understand, and provides a lower cost of ownership (Ralph, 1999). XP emphasizes testing early in the project (tests are automated and are created before any code is written). Unit tests are the main control mechanisms for quality assurance (Ralph, 1999).

Broadly, XP is a set of best practices that contains fairly specific how-to information - that is, it is more of an implementation model than a "one size fits all" ceremonial process. The main activities in XP are listening, testing, and Coding and designing. To further explain what activities means. SS Listening: The development team must prevent extraneous terms and "fluff" in activities. The rules for communication set by the team should promote this. Communicate only what is necessary (Marco 2002).

SS Testing: The clich " ed statement "If it can't be measured, it can't be fixed" has a precursor: "If it doesn't exist, it cannot be measured". Automate all the testing (Marco 2002). SS Coding and designing: Clean code that works is the ultimate goal of any software. This must be religiously pursued through simple practices that promote good design and fix bad design (Marco 2002). The main practices in XP are planning, having small releases, using metaphors or themes, keeping the design simple, unit testing, re-factoring, pair programming, collective ownership, continuous integration, ready access to a customer at the development site to answer any questions the development team may have, and communication with one another throughout the code (using coding standards and comments) (Ambler 2002). XP thus provides a simple set of practices that promote easier implementation and faster turnaround than traditional processes.

Planning in XP, you wait until you have the stories before you begin production coding. The value of this practice is that programmers are relieved of the burden of making decisions that are actually related to the customer's business (Ambler 2002). Programmers implement only features that customers are sure they need, and the customers can change the direction of development (Ambler 2002). Once each story is written down, the scope of the next release is determined, combining business priorities and technical estimates. Technical estimates are gathered from developers. Developers insist on short (three- to four-line) user stories and should not accept any "Motherhood stories".

For example, "The application must be easy to use" is a user story that is not possible to test. There are no objective metrics to follow, nor does this story give a good description of the factors that are important in usability. Ideally, developers would like many user stories that describe these criteria. One of the user stories could be "The users of this system are doctors who have less than two years of exposure to the Internet (Ambler 2002)... The diagnostic user screen should mimic reports commonly used by doctors". This user story has created test criteria that are relatively easy to measure and consequently test.

Having small releases: The main idea in having a small release is that developers get to put a simple system into production quickly and release new versions on a very short (two- to three-week) cycle. The biggest benefit is that customer feedback is gathered early, and, along with the user stories, bugs and feature requests can be addressed early in the development cycle. Using metaphors appropriately Metaphors represent the themes in user stories. A metaphor is a simple, shared story of how the system would work.

The application is built around a small set of metaphors, from which class, method, variables, and basic responsibilities are derived (Ambler 2002). Metaphors promote a common coding and design standard across the team. Another benefit is that everyone knows how the design can be extended. Some amount of brainstorming by the development team and customers is essential to get the right metaphors, and the idea is to come up with common terminology that explains the application".

Writing unit tests Unit tests are one of the cornerstones of the methodology XP emphasizes. In fact, one of the first activities after collecting user stories is to write unit tests. Unit tests should exist before developers write any application code (Marco 2002). The goal is to continually write unit tests and ensure that the application runs flawlessly. Keeping the design simple One of the main business arguments to be made in favor of adopting XP is that software development costs are at least ten to twenty times more than the combined cost of licensing hardware and software.

Thus, the cost of incremental maintenance due to complex design would be far more than the performance gains, if any, of having a complex design. At any given moment, the design must be simple (Beck, 1999). 40-Hour Week The 40-hour week practice states that if you cannot do your work in a 40-hour week, then something is wrong with the project. Let's face it, burned-out developers make lots of mistakes. No one is saying that you should never put in a 90-, 80-, 70-, or 60-hour week, but such a schedule should not be the norm.

An unstated reality to this practice is to make your time count by working hard and getting the most out of your time. Long meetings should be rare, as should unnecessary red tape. Any activity that gets in the way of providing the most business value into the next release of your current projects should be avoided like the plague. Make the most of your time, and 40-hour weeks will be enough most of the time. In addition, keeping normal office hours will give you more opportunity to talk about features with your 9-to-5 customers (Ambler, 2002). Re-factoring Re-factoring is the process of restructuring the code without changing behavior.

Developers might re-factor to consolidate duplicated code, improve communication, simplify, or add flexibility. XP promotes and recommends re-factoring in small steps, which can be stopped any time (Ambler, 2002). Using pair programming In XP, two programmers at one machine write all production code. Conventional logic suggests that such an arrangement would be slower than one in which two people work on two different machines, but this practice (called pair programming) works very well because of the synergy involved (Satzinger, Jackson, & Burd, 2000).

The quality of the code is higher when pair programming is involved. XP prescribes this practice particularly for integration of code. That is, only one pair of programmers integrates a piece of code at any one time. As the design problem becomes complex, pair programming is very beneficial as one programmer addresses the strategic aspects (big-picture architectural issues and review of code as it is being written) and the other addresses the tactical aspects, the naming of the methods, attributes, coding standards, and syntax (Marco 2002). When you consider that subtle architectural errors rather than syntax errors result in hours of debugging, you can see that pair programming avoids the "penny wise, pound foolish" syndrome by promoting simultaneous code reviews (Marco 2002). Ensuring collective ownership No single person owns a module, and anyone can change any code in the system.

After building the program, the developer runs the program against a suite of unit test cases. Anyone who encounters some code that could be improved has to stop and improve it. In smaller projects, everyone is thus familiar with the entire system, and this also acts as an effective risk management mechanism (for example, if a key developer is not available, others will understand the code). The disadvantages of such an approach in larger projects are discussed in the section 'Challenges of Using XP (Marco 2002).

' The bottom line is that everyone is responsible for all of the code. Integrating often XP insists on continual integration. Sometimes the code is integrated at least once a day and sometimes several times in a day. Tests have to run 100 percent before and after integration.

This avoids any massive, conflicting changes in the system. The other rule is that one pair of programmers integrates code at any point in time. Documenting Requirement documentation is done using index cards. During a release-planning meeting, all the members of the team discuss the user stories with the customer and write them down on index cards. These index cards are shown to upper management. There are no lengthy requirement documents or project management programs.

Benefits of Using XP XP is increasingly being seen as a viable alternative for rapid Web application development because of the following benefits: SS One of the best aspects of XP is that it calls for removal of redundant pieces of documentation. In many projects, documentation is maintained as a requirement to conform to some process standard like CMM (Capability Maturity Model) (Marco 2002). Many of the activities are not productive for all projects and are undertaken at the end of the project to conform to the standard. This is one of the pitfalls XP avoids. SS Pair programming acts as an excellent mentoring and quality assurance step in the process. Pair programming also allows instantaneous code review.

Contrary to conventional wisdom, pair programming is very productive (Marco 2002). SS XP can be executed by ordinary programmers. There is no need for specialized architects or project managers. SS XP anticipates change. In reality, almost all projects have changing requirements.

XP is very well suited for applications that have very frequent requirements changes. SS Unit test code is written before the application code is written. This has two benefits: Programmers understand the expected output before they write a single piece of code, and challenges with integration testing are reduced significantly. In this next phase I will try to compare XP to the well-known system development model. The Waterfall Method and XP One of the most widely understood methods of structuring software development is the waterfall life cycle model. Comparing the waterfall model to principles in extreme programming (XP) help to clarify some of the reasons for using XP to develop medium sized software systems with speed and teamwork.

Similarities between XP and the waterfall method are most readily observed at a superficial level. Both methods address planning, analysis, design, and implementation of software. As these components of each method are considered, it becomes apparent that the differences in approach outweigh the similarities. The planning stage in the waterfall method is typically done once at the beginning of the development cycle and is then frozen (Satzinger, Jackson, & Burd, 2000). This is different from the XP approach of iteratively creating, reviewing and prioritizing stories. XP does work to initially determine the scope of the overall effort, but by revisiting the stories or requirements during each iteration, the changes that will certainly be suggested by the customer will be incorporated into the design for the very next release.

In a waterfall approach, the change may not be expressed as a need until after implementation and may then be pushed into the maintenance phase of the cycle. Another difference in the planning aspect of the software is that at any time during the development process using XP methods the customer may choose to implement certain features of the software and forego other features based on current effort estimates (Beck, 1999). In the waterfall method the cost and effort estimations are done in the initial phase of the development life cycle, and are used to track progress and effectiveness throughout the remainder of the project. The difference between analysis phase in XP and the analysis phase in the waterfall approach is both a matter of scope and timing. Analysis done using the waterfall approach is done at the beginning of the project and must be comprehensive in nature. Because the analysis will be important to the remainder of the project, much of the customer interaction takes place in this phase.

This makes the scope of analysis in the waterfall technique very broad and inclusive. In the XP methodology the analysis is done on a much simpler and more modular scale. The analysis in XP is emphasized on the story level, which is a much smaller and simpler activity than analysis of the needs for the whole software project. In the beginning of the development of an XP project, some overall analysis must be done to understand the scope of the entire project, but iterative analysis of the system continues throughout the development cycle. The timing of a waterfall project is different because all of the analysis is done during the initial phase of the project and will not be revisited (Satzinger et al., 2000). Just as the analysis phase of the waterfall method is started and completed then frozen for the project, the design of the software falls into the same sort of approach.

This means that the scope of the design must include every component of the finished product. In contrast the XP model applies design techniques only to the story that is in the current iteration of development. Each story is designed as a product that will meet the requirements using the fewest possible classes and methods (Beck, 1999). This continuous cycle of designing for small components helps keep XP projects focused on short development iterations.

During the implementation phase of a waterfall project the completed product is installed and put into service. This may require extensive cut over planning and user training. In some cases the customer may have had little input or communication with project developers during the coding and testing phases. In contrast the XP model pushes for releases on a frequent basis. Since a customer representative is involved throughout the process and the features are smaller in scope, the training issues will be incremental and easier to address than they would be when implementing an entire software system under the waterfall method.

The concept of continuous integration with previous releases simplifies the implementation of each release (Beck, 1999). Each of the above components of the waterfall method has a corresponding element in XP. The XP approach has taken the building blocks of the waterfall method and cut them into smaller pieces, then put them back together in a different order so that the process occurs over and over to construct a different way to produce software systems. These differences allow more flexibility for the customer and the design team throughout the development life cycle.

Conclusion Extreme programming is one of the newest software development models out there today. Even though it is still a new model, it does have less overhead and is organized differently than the other models. I think in due time the XP model will have a chance to mature and programmers that want to speed up development time and are willing to try something that is quite different from the traditional approach to software development will latch on to it. With XP requiring less documentation, programmers can speed up and complete their projects faster, but in smaller increments. Over all, The XP methodology will allow a small development team to be very productive on a small to medium sized development project. Reference "A gentle introduction " (August 17, 2002) web Scott W. Ambler.

(2002) "Agile Modeling and eXtreme Programming" Effective Practices for eXtreme Programming and the Unified Process, Lou Marco (2002) "Extreme Programming in a J 2 EE Project" Java On The Edge, Unlimited Edition, Satzinger, J.W., Jackson, R.B., & Burd, S.D. (2000). Systems Analysis and Design in a Changing World. Cambridge, MA: Course Technology, a division of Thomson Learning. Beck, K. (1999). Embracing Change with Extreme Programming.

Computer, Johnson, Ralph (1999) "Extreme Programming web.