The Extreme Programming is also tailored towards a single project to be developed and maintained by a single team, however, in real life many organizations prefer to keep the crucial aspects of software development like data management and release management concerns outside the purview of regulations of a single project manager. The Extreme Programming technique is quite susceptible to adversely affect the 'bad apple' developers that do not have necessary inclination to work well with others and knowing it all, and/or are not inclined to share their 'superior' code with others. Even though these developers are an obstacle to any project and sometime prove detrimental to the organization in the long run, the dependence of Extreme Programming on communication and teamwork simply bars them from the group activity. (Adopting Extreme Programming: Successful integration of XP into your organization requires the support and buy-in of senior management - Technology Information)

Irrespective of the fact that some managers are firm to attach themselves religiously to this approach, the Extreme Programming is not favorable for every team or every project. As per the advocators of the Extreme Programming, some factors make some projects better suited to this methodology than others. Determination of the size of the programming team is considered to be the first prime issue in this respect. Normally, the Extreme Programming is considered to be most effective in cases where small teams are associated particularly in two to twelve programmers. The small teams are considered to be more flexible and capable of adjusting themselves to change than involving the monstrous teams consisting of fifty or one hundred persons. In order to use this approach it is considered pairing up of the team with each sharing a single computer and each counterpart concentrating on a different dimension of the problem. (When eXtreme Programming Makes Sense)

Normally, writing and implementation of the code is done by one programmer while the other observes for syntax and spelling errors, along with the idea of place of the present piece into the whole work. The obligation to Extreme Programming is resorted to run throughout the organization from the top of the hierarchy flowing down to the programmers and even to the level of the customers. In order to use the Extreme Programming effectively, at least a small fraction of the customer base is required to be interested in and capable of being involved in developing and testing the application. It is suggested that one more customers are associated with the development teams and the representatives of the customers are also required to be experts who actually use the application, assuming them to have a deep enough insight into what it is that the product needs to be able to achieve for them. (When eXtreme Programming Makes Sense)

After accessing the user experts, they are required to make them write a short description of the user stories and the details of the feature that is desired. Once the team prioritizes the user stories for adoption and incorporation in the next edition of the program the customer chooses the features that will be worked out first. They then also assist in planning the acceptance tests those are considered to be the sequence of the automated tasks the program can be put through to ensure that it is doing what is supposed to be doing. The customers are also capable of visualizing the test scores and checking the matters themselves ensuring that the tests assess the things in a proper manner. The project in which the constraints are not stable and in which the requirements frequently vary, the Extreme Programming is considered to be the best alternative. The Extreme Programming is not considered however a good alternative for those who have a nice flat set of needs.

The other spheres where the XP is suggested as a methodology is the circumstances when the teams visualize itself treading into unfamiliar territory. Most of the programmers have established themselves working in companies where management is taken to be fanatical with the XP way that the Extreme Programming is considered solution to all problems; and resistance to this in any form over this approach is considered to be losing of ones job. Such an environment is not favorable to the employee situation even when they are not trying to investigate the way everyone works upside down. The change is considered to be risky. The presentation of the reasons in a constructive manner is highly essential. Besides it is required to adhere to the concerns of the people and anticipate that the first project is taking a longer time than anticipated. (When eXtreme Programming Makes Sense)

Since...

In case of large projects several smaller teams are conveniently joined together. The Extreme Programming depends upon the development into bite size chunks and relies on daily face-to-face team communication and lots of testing, the hypothesis that specifications will vary is built into the process. The projects are developed in augmentations with sufficient code generation for implementation of the desired features and everything is constantly assessed and adjusted to accomplish the desired result. (Munro, Extreme Programming)
To conclude, the Extreme Programming is a field of software creation mostly relying on the principles of the simplicity, communication, feedback and courage. The critics of Extreme Programming visualize that it merely incorporates best experience prevailing for years. The critics are considered true to the extent that the process of programming is Extreme in utilizing the best practices in every respect. The assurances of XP- a well designed and well tested code are always distributed on time and within the financial constraints. (Munro, Extreme Programming) it works by uniting the whole team together in the presence of simple practices with sufficient response to enable the team to be aware of their position and adjust their practices to their unique environments. (What is Extreme Programming?) Irrespective of the fact that the Extreme Programming is not considered to be for everyone, it is most likely for a lot of project teams that desires to effectively produce the software-which makes the strategy more attractive.

Language prototyping prototype can be considered as a depiction or imitation of a suggested answer to a design puzzle, irrespective of the medium. The usual application of prototypes is for utility assessments carried out in the design stage of an assignment. For such an assessment, the design team spots jobs characteristic of those that the users of the product will carry out, chooses a group of users to take part in the utility trial, and monitors how well the members carry out these jobs. If the participants have trouble carrying out the jobs, alterations are made to the design and further utility experiments may be attempted. Prototyping is an outstanding method of designing the user interface and it includes screen layouts, control labels, and other graphical user interface - GUI characteristics. (Extending prototyping)

Prototyping is an efficient technique to get awareness of the necessities, lessen the intricacy of the problem and offer an initial corroboration of the system design. For computer aided prototyping of quality domain-specific software, there has been no generally acknowledged executable specification language or high-level programming language. Available prototyping devices are either too focused to be helpful in a broad range of application domains, or too complex to utilize by non-computing professionals. Furthermore, some specification or prototyping languages or devices aid reusable prototyping. In the majority cases, an acknowledged prototype has to be re-used in a usual programming language. (Rapid Software Prototyping Using Visual Language Techniques)

Language prototyping refers to creating language implementations mechanically from high-level language descriptions. (Language Prototyping: An Algebraic Specification Approach) Any type of language, which is inclined towards power of expression, neatness of actual code, and quickness of development, with eventual efficiency taking a relative back seat, is Prototyping language. There is a squabble that proceeds like this: 80% of the code takes 1% of the CPU time; 10% takes 10% of the time; and the last 10% takes the rest. If you can substitute that 80% by 10% at the price of that part of the code running five times slower, your cost in operation is minor and you've removed 70% of the code. (Prototyping languages: www. home.tiac.net) language should be considered as a group of language bits, each bit defining a separate and reusable modular element. (Modular Attribute Grammars for Programming Language Prototyping) Program languages can be expressed as a language that expresses the alteration and power of an existing program. Program languages can be made from one or many basic programming languages, and actually can be applied as part of the functionality of the prototyping environment. This opinion is made on the insight that a setting is a means to help a programmer in making a working program, including planning the source text. There is no compulsory necessity that an environment be restricted…