What Is Extreme Programming

Published Date: 02 Nov 2017

EXTREME PROGRAMMING

Agile modeling has become the talk of the industry these days. It refers to a software development practice, which is considered to be more flexible than traditional software development practices like waterfall model, RUP model, Spiral model and others.  Many software companies are moving towards adopting agile methodologies leaving behind those traditional developmental models.  The different developmental practices in agile include Scrum, Extreme Programming, Disciplined Agile Delivery and Agile UP.  This paper will talk about Extreme Programming by first giving an introduction to the methodology. It will then give a brief introduction to practices involved in extreme programming and then explain four practices in detail followed with analysis of those practices. The paper also presents one case study on one of the detailed practices.

What is Extreme Programming?

Extreme Programming, shortly abbreviated as XP, is the most widely used methodology in Agile Practices. It comprises of twelve "interdependent" developmental practices. It is a methodology that nourishes in a team environment and is highly collaborative in nature. Here, the team participates in all the aspects of the development form tip to toe. i.e. the entire team gets involved and works together right from planning till the release of the product. The XP methodology adapts "simple practices". The disciplinary nature of the XP makes it mandatory to follow set rules while practicing it all the time. The Customer is at the center of the team and is the core focus of the developmental process. "Regular feedbacks" are taken from the customer at every step. This is a similar situation we observe in the recent market economy, wherein the strategies and practices of any business are centered on the customer and the ‘customer is the king’! Hence, before the product is approved for the release, it has to go through the customer satisfaction test and gets the green nod for release only if the product passes all the tests and is validated by the customer as the final authority. For the product to pass through this intense phase, it needs to be developed putting into consideration the requirements of the customer himself. So, in the first step, the team rosters and plans the features based on the requirements laid forth by the customer. The final plan is devised if the customer approves the pooled list of requirements for the project to begin. The team follows the plan rigidly and tracks their progress regularly and intermittently to assess their current standing, the progress made and the targets to be achieved. The team applies "incremental" approach for product development in which the "small integrated" product versions are released. The release cycles are short and the released product is integrated into the main product. On the other hand, the main product is continuously running and being tested for the performance of "small integrated releases". XP immediately responds to the changing customer requirements (if any) and tries to incorporate them into the product through their incremental small versions. This makes XP a highly flexible and supple development strategy. In XP, the ideal team size is between two to ten members and the code is written "in pair" or "in group". Here, no code is owned by any programmer. Any programmer can access and change the code for any part of the product. Every member of the team follows a "consistent" coding practice minimizing or nullifying inconsistencies that would arise if such an open practice will not be there. The other benefit is also that any member can work on the code the other members of the team and can improve upon it. It requires constant "feedback" to see where the team stands and to improve upon the practice the team is following.

Practices followed in Extreme Programming (XP):

In this section we will briefly talk about twelve different practices, which are followed in Extreme Programming. These different practices are organized in three different zones. To have a successful implementation of XP, it is formidable for the XP team to abide by those twelve practices and strictly follow them. As the team gets proficient in using those practices, they gradually modify as per their use and even incorporate some practices or remove some to serve the purpose better. The entire structure of XP revolving around these practices is depicted in the figure below:

circlesFig.1: Source: http://www.xprogramming.com/xpmag/whatisxp.htm

The outermost circle, also called as the "Planning Cycle" takes place between the customers and the developers. The middle circle represents "Team Collaboration and Coordination" to produce high quality product while the innermost circle depicts the "Core Methodologies" to be followed while implementation of XP.

Planning Cycle:

Whole Team – Every member of a team works as a single unit. The team comprises of Customer – usually the end user, Analysts – aid in defining customer requirements, Testers – assist customer in developing and running the ‘acceptance tests’, Programmers – who develop the program, Coach – the time tracker and the motivator and Manager – who coordinates resources, utilities and communications within the team. The team will get "requirements and priorities" from the customer. Customer is also the one who guides the team and gives direction to the project.

Planning Game – It involves two key practices namely "Release Planning" and "Iteration Planning". In the former, based on customer needs and priorities, cost estimation and important features are depicted as a plan by the customer, which is called "Release Plan". The second one is "Iteration Planning" where the team tries to deliver runnable software by the end of every iteration period. The customer feeds in the desired features he wants from the next round after the end of each iteration period.

Customer Tests – Here "acceptance tests" are defined and run by the customer to verify the correct implementation of the features he desired. This is also a stage where the developers need to prove the customer about the correct implementation of the features they were expected to deliver. These tests are automated to withstand the time crux. The customer can approve or reject the product at this step if he is not satisfied with project implementation.

Team Collaboration and Coordination:

Coding Standard – Extreme Programming team adhere to similar "coding standards", so that it appears as if one individual does the coding. This practice is useful and supportive for another practice that is "Collective Code Ownership".

Sustainable Pace – Extreme Programming team works for an elongated period of time and for that they need to work at a continuous pace. The team sometimes needs to work overnight if they are running behind the schedule or else have to work for the normal allocated work hours.

Metaphor – It is absolutely essential that every member of the team understand the project they are working on at all times. There should be a clear vision for the best development to happen. Hence, the team describes the project with a common term called the "Metaphor". This helps to find and place the right functionalities by any member of the team.

Continuous Integration – XP team keeps the system running all the time. The multiple builds that are produced daily are regularly integrated into the main product. There are multiple benefits to this as against infrequent integrations. If the integration is infrequent, despite of developing the perfect codes, the integration might fail without any detectable reasons. Besides, an unintegrated system cannot detect problems in the codes leading to development of ‘buggy codes’. Finally, irregular or infrequent integrations freezes the codes which are important to be delivered to the end user in a short span of time.

Core Methodologies:

Design Improvement – Extreme Programming continuously evaluates and improves the software design. This process is called "refactoring". It removes poorly designed part and increases the code "cohesion" and decreases code "coupling". Continuous improvement is essential for XP to keep abreast continuous integration yet retaining the aesthetic appeal of the software.

Simple Design – In Extreme Programming, the design is kept as simple as possible. The focus is kept on design all the time through the entire course of development with enough scope to incorporate new functionalities to the system.

Most Critical Methodologies

Small Releases – The deliverables are frequent in the form of ‘tested software’ based on the features demanded by the customer. These releases take place at the end of every iteration period. In this scenario, a customer lists expectations for a current iteration period and the team tries to produce a runnable prototype of the product meeting the customer’s list of requirements. The customer runs ‘analyzer tests’ on such small releases and evaluates the performance of the test release and whether it met the expectations or not. If satisfied, the new set of requirements is enlisted for the next round of iteration. If not, the developers have to redevelop the product that meets customer’s expectations. The other form of release is on the web directly to the end users. The frequency of such releases is monthly or quarterly. Customer patronizes such a practice for its iterative validation and approval at regular intervals. However, in the latter case, the releases directly to the end-user are not refactored if there is any underlying bug or problem.

Collective Code Ownership – In Extreme Programming, one of the practices that are followed by the team is the "Coding Standard". Hence, every programmer in a team follows a common coding style and standard so that the code looks familiar to every member of the team. Collective Code Ownership allows the members of the team to work on any code and on any section of the product. Since, there is no concept like "individual code ownership" in XP, anyone can work on anyone’s code; either to add "valuable enhancement" to the code, to complete the work or to remove a bug from the code. This makes every member of the team at least somewhat familiar with every section of the product. The knowledge will definitely vary based on the amount of work one has performed on a particular section. Moreover, in XP, entire team is responsible for the system and if problem occurs in some particular section of the code, then no one can play the blame game.

Pair Programming – Pair Programming is considered to be one of the "core" practices in Extreme Programming. In Pair Programming, two programmers work together on the same machine (single screen, one mouse and one keyboard). Here, one programmer will work on the code or will write the code while the other will review it and will look at the overall structure and flow of the program. The one who is writing the code is called "Driver" or "Pilot", while the other is called the "Navigator". Generally, after some time the roles are interchanged so that both of them get the chance to work for both the roles. Moreover, it is expected that the driver should speak out loud while programming, so as to keep both the driver and the navigator engaged. If the driver does not do so, the navigator should interrupt and ask him to do so. Usually, the pair keeps changing and is not fixed. It may happen that in the morning, one developer is working with some developer in a team and at the end of the day; he might be working with some other developer. A member, if working on a particular product that he is unaware of, might ask the team member who is more experienced in that particular field to pair with. In this way, knowledge gets distributed and the team spirit gets stronger day by day.

Test Driven Development – Test Driven Development, in short TDD is a software development process that focuses on writing testing code preceding or simultaneously with writing functional code. It does not allow writing testing code after development. This is helpful because it can accommodate changes repetitiously. TDD has a simple basic idea. Prior to running or implementing the codes, the new tests are written. They might fail initially but would help to demonstrate how a new feature or a bug-fix should work once completed. Then the code is written and is tested on the pre-written tests. If it does not pass, the code is "refactored". This practice is repeated for all the new functionalities to be added in the software. Besides, the code needs to pass not only the developer’s tests but also the tests written by different programmers for that particular functionality. Once, the code passes through the repository of tests, it is allowed to be integrated into the system. This way, the entire software is developed incrementally and repetitively. TDD has become a popular way of building good quality software by writing unit tests before writing actual functional code. TDD is advantageous because TDD is not just testing and validation of the code. It also helps in design of the program and the software. By focusing on the test cases first, programmer must imagine how clients use the functionality. So, the programmer is concerned with the interface before the implementation. This benefit is complementary to Design by Contract as the former approaches code through test cases rather than through mathematical assertions or preconceptions (as in latter).

ANALYSIS

Analysis of problems and advantages in Small Release practice: In this practice, the customer runs automated tests on the products to validate the list of deliverables expected. These tests are many-a-times not designed by the customer himself. However, a Helper from the team of developers works to translate the customer’s requirements into automated tests. Foremost of all, such tests do not completely reflect the requirements of customers as not all the requirements can be translated into a testable program. Besides, the customer can approve or reject the releases at each iteration period. Also, the customer has to be present at the end of each iteration round to test the deliverables. This may incur heavy losses if there is inefficient organizing and coordinating the meeting with the customer and the team. Any discord in organizing this test event may pique the customer and in turn can have negative influences on the product approval. If the release is rejected, the time and resources invested during that period are wasted and influences subsequent stages of development. Moreover, any change in the expectations of the customer at any period may change the course of the development process and could be resource intensive and if not dealt properly, can lend heavy losses to the shops.

On the other hand, it can be argued that the ultimate aim of the business is to keep the customer happy and since the customer/customer-rep represents only a single individual, it could be relatively easy to get approval and live upto his expectations then if it has to be approved by a panel of end-users. I personally believe that interpersonal co-ordination with the customer can tackle lot of issues precipitating due to organizational conflicts. A coach in the team can play an effective role in organizing and communicating to the customer whereas the helper who designs tests for the customer can give valuable inputs by delineating the specific needs of the customer to the developers.

Analysis of problems and advantages in Collective Code Ownership: On prima facie, this practice offers many advantages over disadvantages. The only crucial disadvantage that may shield the advantages is the provision for any member of the team to change the codes in any section of the product. Although, it is intended for ‘value enhancements’, yet we all know that ‘’too many cooks spoil the broth’’.

However, under the sky of optimism, it provides an access to other members to continue the work in the absence of some. It encourages each developer to feel responsible about the system and contribute to product development. It can significantly improve the quality by putting diferent minds into it. So, I believe, the advantages of CCO in XP surpasses the disadvantages.

Analysis of problems and advantages of Pair-Programming: The philosophy behind pair programming is to put two developers together so as to develop codes by inputs from both the programmers on the same module. The logic behind pairing the programmers is to increase the per-programmer productivity as compared to when they will work alone. Here both the programmers interchangeably adopt different roles during the code development as described above. This is a dangerous situation wherein mutualism can soon turn into parasitism and hinder the relationship of the pair. Some people also feel that pairing creates a sense of inferiority or superiority based on the standing and experience of the paired partner. This can lead to rapid loss of enthusiasm in the working pairs and can waste resources or yield dirty, unstructured codes, which will keep piling up in the system. Hence, a major sector of the industry is refrained in adopting paired programming practice.

On the contrary, many well-respected programmers prefer paired programming as they feel it is a faster, efficient and reliable way of creating successful codes with higher success rates in test cases. Sometimes, even novices can contribute in a useful fashion to seasoned programmers and this also is an efficient way of sharing the knowledge. It has also been argued that having two programmers jell together on the same code makes their work enjoyable and produces highly efficient and smarter codes. I would stand to agree to the latter argument wherein I feel that paired programming can immensely increase productivity and efficacy. One, only needs to have a cordial communication with their partner.

Analysis of problems and advantages in TDD: As described above, the test codes are written prior to writing the functional codes to validate the functionality of the new codes. It not only needs to pass the developer’s tests but also all the tests designed by other developers for introducing a particular functionality. Hence, it could be possible that the test design by one or more developers may not be compatible with the codes written by other developers. In such a case, until and unless the developers write codes that can pass all the tests, new functionality or bug-fix cannot be introduced into the product. This can cause long freeze times for the problems to be addressed by developing new codes. Moreover, the TDD practice relies continuously on optional scopes and refactoring for the final product development. Due to this, the developers and the customers may be totally out of context in imagining or expecting what the final product to be delivered will look like. Many a times it may be a feasible idea to create codes and execute them to create a prototype product which can be approved for development rather than TDD. Moreover, the programmers have to imagine the preference of client interfaces, which could vary on individual basis and may not represent the preference of the masses. In such a case, final product developed on TDD may fail completely despite of its error-proof functionality.

It cannot be undermined that TDD has been the most preferred method of software development for over three decades. This is clearly understood due to its stringent testing regimen for the incorporated functionalities. However, I am convinced that relaxation in the testing strategy can speed up the development process and it could be highly informative to assess the product by first developing it on some assertions, conceptions and a few test cases to have an estimate of client preference towards the interface and functionalities.

CASE STUDY ON PAIR-PROGRAMMING

Most of the investigations led to assess the success of Pair-Programming considered parameters such as Economics of the code development and defect removal, Satisfaction of the working partners, Design Quality of the codes developed, Problem Solving ability of the pair, Time consumed in developing, Team Building and Communication in the pairs. In this section, I will shortly brief the outcomes of a few case studies on Pair Programming including a unique one done by Nick Flor in 1991. Flor studied different parameters on paired programming and made some interesting conclusions based on his findings. These conclusions are summarized here:

Different partners bring different prior experiences to the task and have different access and interpretation of task relevant information.

They have different stands in context of the problem due to their different functional roles.

The negotiation resulting in case of conflict of opinion often results in choosing a hybrid line of code which turns out to be superior to what they would have individually developed in response to the same problem.

Through some different studies, it has been observed that working in pairs only cause marginal increase in the time spend for code development (Fig.2) thus not affecting the economics of the code development. However, the number of test cases approved by paired programming are significantly higher than those approved from individual programming (Fig.3). In a similar study, the pairs developed smarter codes by incorporating the same functionality in fewer lines (Fig.4).

Fig.2 Fig.3 Fig.4

CONCLUSION

In the emerging market wherein globalization and customer satisfaction has changed the book of business practices, XP offers many advantages to develop products that are functionally robust and are developed through iterated feedback and approval from the customer. XP practices symbiosis wherein the inherent flaws in any of the single practice strengthen each other when combined together. This can be advantageous as there is a collection of ideas and codes pooled together to churn out the best product. For efficient and successful delivery of the products to reach the market, it is essential to build a team of Extreme Programmers who work together at the best of their efficiencies. Due to its ‘all or none’ nature, XP is a courageous practice that can fall like a cascade if any one practice fails to abide by the set compendium. Nonetheless, if practiced 100% with the most philanthropic and co-operative working mindset, XP can yield robust and smart products being fueled by intensive customer feedback.