What are the common mistakes and misunderstandings in extreme programming?

The extreme programming saw its first use in the year of 1996 when it was declared as an agile software development process. Because of its down to earth and effective rules it gradually gained wide popularity among the programmers and developers and is still on the edge of the evolution. It has been observed to be quite successful with all the kinds of companies’ whether small scale or large scale. The extreme programming facilitates the daily communication between the customers and the developers so that they are aware of the changing requirements of the customers.

The extreme programming though being so popular has always attracted controversy due to some mistakes and misunderstandings regarding its usage and concepts. In this article we are going to discuss about these common mistakes and misunderstandings regarding the extreme programming. 

Misunderstanding # 1:

- Some people have a misunderstanding regarding the flexibility of the extreme programming development process.

- They think that having an on- site customer making changes in the requirements can cause the team costly re-work and the project may expand beyond its scope and of course budget.

- The extreme programming is dependent to some extent up on an assumed unified client’s point of view so that the programmer faces no difficulty in programming rather than on documentation. 

- The same situation arises when many organizations compete to get the shares of the projects.

Misunderstanding # 2:

- One other misunderstanding regarding the extreme programming is that the requirements are considered not to be expressed as specific documents but as the automated acceptance tests. 

- In extreme programming all the requirements are not retrieved in advance like in other development processes but they are obtained one by one in successive iterations and increments. 

Misunderstanding # 3:

- Another misunderstanding is that the programmers and developers are required to work in pairs compulsorily. 

- It is not so but it depends up on the situation, budget and quality level of the software project required. 

- If the time is less for testing of the code, then it is always advisable that the programming is carried out in pairs. 

Mistake # 1:

- Another mistake that is made by the developers is that they carry out most of the activities on fly in extreme programming. 

- This follows from the idea that the simplest necessary feature is implemented first and later the complex features are added if required.

- Most of the people fear that such kind of activities can later force the team to re design the whole program. 

- Some think that having an on- site customer can cause a lot of stress to the development team and micro management may take place with the customer who basically does not have any knowledge of the technology dictating the whole development process. 

All the aspects of the extreme programming are considered to be chained together. Even if one of them gets loosen then the whole programming will be spoiled. It is believed by most of us that extreme programming is carried out by small team consisting of around 10 members! But this is not so, the size of the team can be expanded as required by the project but it should always be the minimum possible number. 

Another alternative here will be to break down the project in to smaller divisions and also divide the team as per the project divisions to keep the discipline of the extreme programming. 

Most of the people view the extreme programming as a rigid process which is absolutely wrong! The extreme programming does allow modifications in its rules but on the condition that its spirit is not violated.