Software DevelopmentThe Emergence of Extreme Programming

The Emergence of Extreme Programming

Extreme Programming

Software Development is a systematic process that typically comprises of 6 main phases, namely requirement analysis, designing, coding, testing, deployment and maintenance. However, it is very difficult to freeze requirements and strictly follow a linear-sequential model for developing software. Client requirements keep on changing for one reason or another. Inaccurate requirements specified during the project give rise to software bugs that are costly to repair at a later stage. Moreover, changes in political, legal and business environments force companies to make constant changes in their software applications. Experts have come up with a number of alternative software development models that aim to mitigate the risks associated with changing requirements. A new approach to software development recommends developing software in a series of iterations to accommodate the ever-changing business requirements. This agile approach is termed as ‘Agile software development’ and ‘Extreme Programming’ (XP) is the one of the most prominent of agile methodologies used today.

XP: A Prominent Agile Methodology
Extreme programming is an agile development method that takes all the phases of software development to extreme levels. More particularly, XP achieves the goals of agile development by laying emphasis on extreme team collaboration and communication. For example, every XP release cycle begins with a planning phase that involves a high collaboration of customers, team leaders and programmers. All the stakeholders attend a meeting called as a ‘Planning Game’ in which the scope of the release is decided by prioritizing user stories or product features. XP also stipulates that a pair of programmers work together on the same code. This ensures that a high quality of code with little bugs is developed during the project. This ‘pair programming’ ensures that the code is reviewed on a continuous basis as the two programmers are simultaneously working on the same code. XP uses a test-driven approach which means unit test cases for each software object need to be prepared well before the coding.

XP: The Beginning
XP techniques were formulated by Kent Beck, an Oregon based software professional, while he was working leading the Chrysler Comprehensive Compensation System (C3) project; a large and complex software project that replaced Chrysler Corporation’s various payroll systems with a single business application. The C3 project had run into trouble before Ken was hired to streamline the processes. Lack of collaboration and cooperation amongst the team members had almost derailed the project. The high level of code redundancy and complexity made managers doubt whether the application will successfully work in the production environment. Ken decided to put fix things by borrowing some of the best practices from emerging agile methodologies. Ken interviewed every programmer individually and chalked out a process that made all the programmers work together to integrate their code. Later, pair programming was introduced and the code was released at least once in a day. Programmers began sharing the same computer for improving collaboration. Ultimately, the collective ownership enabled the team to achieve its goal and the project was completed as per the project plan and timelines. The C3 project was the first ever software project to foster ‘collective ownership’ and extreme collaboration. And thus, XP was born.

The VCAPS project: XP Gains Stronghold
XP evolved further when Don Wells used the best practices while working on Vehicle Cost and Profitability System (VCAPS); a project of Ford Motor Company that calculated the cost of building a vehicle. During the course of the project, the practice of developing a ‘unit test framework’ was introduced to reduce bugs. This was the first time that any project team had prepared detailed unit test cases before diving into the coding phase. This intermediary step enabled the programmers to complete coding within one week. Moreover, the code was delivered without any bugs. More XP practices were introduced and the project delivery rate was improved by 10 times. The successful completion of the second XP project showed that extreme programming was a very practical approach to overcome the shortcomings of other methodologies.

Today, the XP framework is upheld by five key values, namely communication, simplicity, feedback, courage and respect. The framework encourages programmers to adopt simplicity and express their opinions fearlessly. Moreover, project goals can be easily achieved by constant communication and feedback. Ultimately, the mutual respect towards each other is the key driver of any XP project. In his book ‘Extreme Programming Explained’, Kent Beck has defined the following 12 best practices that are adhered to in XP:

• The Planning Game
• Short Releases or release cycles
• Metaphor or a narrative
• Simple Design
• Testing
• Refactoring the code
• Pair Programming
• Developing a sense of ‘Collective Ownership’
• ‘Continuous Integration’ for fostering a sense of responsibility
• Following a ‘40-hour-week’ schedule for a healthy work-life balance.
• Presence of an ‘On-site Customer’ to foster communication
• ‘Coding Standards’ to ensure uniformity and simplicity

XP: The Future
Despite its several disadvantages, extreme programming has faced criticism from several experts. This is because the methodology focuses more on coding rather than design. Software professionals who give importance to design and documentation avoid using XP and rely on other agile methodologies like Scrum. Many experts have suggested combining Scrum and XP for gaining maximum advantage. It is easy to combine these methodologies because both of them are based on agile principles. It is important to remember that the two methodologies differ from each other in few areas. Firstly, both the processes have different semantics. XP has shorter duration of iterations as compared to Scrum. Secondly, XP focuses on strictly prioritizing work items while Scrum process allows working on low priority work items if required. The main difference is that Scrum stipulates the maintenance of artifacts and meetings while XP focuses on the usage of engineering best practices. Many Scrum masters are seen adopting the best practices of XP to reap the benefits of both methodologies. As XP continues to evolve further, the domain of software engineering will continue to see agile practitioners coming up with their own versions of XP.



Please enter your comment!
Please enter your name here

Exclusive content

- Advertisement -

Latest article


More article

- Advertisement -Eduonix Blog