User:Didibagle/sandbox

The History and Evolution of Extreme Programming (XP) is not extensively documented since it, like many different Agile software development techniques, is relatively young when compared to the Waterfall model. Many software companies, who haven’t transitioned over to this new school of development processes, have at least heard of or read about it. With XP, many practices have been around for a while but evolved over time. The major difference is that everything is taken to the extreme with XP. This article recounts the history of the XP and how it evolved over time.

The three Extremos ^[1]– as how they were called, were the three major individuals who were considered to be the Fathers of Extreme Programming. They are Ward Cunningham - inventor, Kent Beck – articulator and Ron Jeffries – realizer.

Extreme Programming came about in 1996 at the Chrysler Corporation even though various practices of the XP such as pair programming started well before then. Kent Beck was initially hired as a consultant to optimize the C3 system’s performance. The C3, or Chrysler Comprehensive Compensation System project, was a project in the Chrysler Corporation to replace several payroll applications with a single system.

Chrysler first brought in Kent as a consultant to help tune the performance of the C3 system. After the hiring, Kent’s first major task was to spend a half hour with each of the developers to get an idea of what needed to be done. When he began talking to Don Wells, he ended up spending 3 hours. It was apparent at the end of the conversation that the current code base would never make it into production. Later, Kent presented the findings to Chrysler’s management and they agreed. Kent was eventually retained to coach the team.^[2]

Prior to the formation of the first XP team, the project, to design a payroll application, started back in 1993 and had yet to print a single paycheck 3 years later. With Kent overseeing the project, he brought in Ron Jeffries. The team estimated that one year was needed for the restarted C3 system development project to go into production. In the end, the XP team largely delivered the payroll application in the one year time it had promised if it were not for the lack of clarity on some business requirements.

Kent’s approach on the C3 project was to mix together the best practices from several emerging agile processes with things he had learned while working with Ward Cunningham. The C3 team created a new process formulation by watching what helped or hindered. Doing more of what helps and less of what hinders resulted in a minimal process with high flexibility. Kent decided that beneficial elements of traditional software engineering practices should be taken to “extreme” levels. In Kent’s mind, when he first articulated XP, he had the mental image of knobs on a control board where each knob was a practice that from experience he knew worked well. He wanted to turn all these knobs up to 10 and see what happened.

Extreme Programming is still young and has only been in existence since the late 1990s. The process and its practices are still evolving as organizations that adopted the method are finding out what works and doesn’t.

Pair programming is the practice of having two developers work together to write code ^[3]. As Laurie Williams detailed in her paper Pair Programming^[4], the idea of pair programming actually came about in the mid-fifties where Fred Brooks, author of The Mythical Man Month “tried pair programming when I was a grad student (1953-1956). We produced 1500 lines of defect-free code; it ran correctly first try.” It wasn’t until the late 1990s/early 2000s where pair programming practice was brought to the forefront due to the emergence of the XP software development methodology. Professor John Nosek of Temple University, in 1998, was the first to study on the efficacy of pair programmers.^[5] The study found that team groups completed the task in question 40% more quickly and effectively by producing better algorithms and code in less time than individual groups. Even though pair programming will cost more in the short term, there is no question that the code produced is of higher quality – leading to lower maintenance costs down the road.

During the early days of Kent’s involvement on the C3 project, he wanted to integrate code often but wasn’t working as the software architect had to step in to help which slowed down the progress. Don Wells, who was hired to the C3 project as an expert in object technology and GUIs, cleverly proposed that the team setup an extra computer on an empty desk to be solely dedicated for code integration. Team members would be able to integrate and release new code to the repository whenever they wanted without prior permission as long as all unit tests were run. As the project progresses, the code was being released at least once a day, team members were more co-operative and the design fitted tighter since everyone was ultimately responsible for making it better. This led to team members writing more unit tests than before since it would help ensure their code would run even if someone else makes some changes. The entire team collectively owned the code base and allowed the team to work much faster than before. Don estimated that the team was going six and a half times faster compared to prior. ^[2]

After seeing the C3 project back on schedule, Don Wells moved back to [Ford Motor Company]. and dove into developing an application that would help calculate how much it costs Ford to build a car or truck – Vehicle Cost and Profitability System (VCAPS). Problems were already mounting before Don stepped in; the application had serious quality and performance issues and time were mainly spent on bug fixes rather than feature additions. Don’s first big change was to institute a test-driven development (TDD) strategy by writing unit tests and test frameworks. The unit tests and framework took the entire first two weeks to finish. But once the unit tests were in place, the actual code only took one week to write and no debugging was needed. The assignment was finished on time and none of the expected bugs. Eventually, the number of unit tests grew and management noticed a one third reduction in production bugs.^[2]

In 2000, Bill Wake, who maintains a website at http://xp123.com, came up with a visual indicator of XP practices adoption to help organizations assess how well adapted to XP they are.^[6]

Scoring

Give a 0 (worst), 1, or 2 (best) for each entry then add up the score for each category. Plot that score on the corresponding axis then connect the dots.

Programming

__ Test-first programming

__ Automated unit tests

__ Simple design – embodying "You Aren't Gonna Need It" (YAGNI)

__ Merciless refactoring – part of the development cycle, code appears "once and only once"

__ TOTAL "PROGRAMMING" SCORE

Planning

__ Planning game – explicit customer and programmer roles, story and task breakdown

__ Frequent/small releases – delivered to users every 1-3 months

__ Short iterations – days to weeks (then delivered to Customer)

__ 40-hour week – team not relying on sustained overtime to maintain its pace

__ TOTAL "PLANNING" SCORE

Customer

__ Dedicated customer – primary responsibility is to be customer of the XP team

__ On-site customer – sits with the team

__ Automated acceptance tests

__ Customer steers – the plan is flexible so the customer can change it at any time

__ TOTAL "CUSTOMER" SCORE

Pair

__ Pair programming – all production code developed by pairs

__ Open workspace – everybody in one room

__ Collective ownership – any pair can change any code

__ Integration machine – machine (or at least token) used to reserve main line of code

__ TOTAL "PAIR" SCORE

Team

__ Continuous integration – at least daily by each pair

__ Unit tests maintained at 100%

__ Metaphor – core names & relations that everybody understands

__ Coding standard – that whole team accepts and uses

__ TOTAL "TEAM" SCORE

Eventually, XP evolved overtime and there are 4 major areas with 12 common practices in total. Many of the methods suggested below are already incorporated in some manner within the [Agile software development framework. ^[7]

• Pair programming
• Planning game
• Test-driven development
• Whole team

• Continuous integration
• Refactoring or design improvement
• Small releases

• Coding standards
• Collective code ownership
• Simple design
• System metaphor

• Sustainable pace

Many people often wonder about the differences between XP and other Agile software development methods. The main distinction with XP is that everything is taken to extreme levels. Michael Dubakov states that he doesn’t “see much difference between XP and Scrum.”^[8] If you already utilize XP in your organization, you may just want to add some other Agile specific practices such as the use of Burn down chart. There is no silver bullet in whichever way one chooses to deploy for his organization. Rather, one should transition to an Agile method that best fits the organization’s culture and discover the shortcomings along the way. During retrospective meetings, come up with a list of improvements and apply them iteratively until the team is happy. Then, keep on iterating because one can always continuously improve.

Just as the Extreme Programming Explained book written by Kent Beck stated clearly on the cover page, one should “Embrace Change.”^[9] The advent of globalization is forcing companies to rethink about competitiveness to lower cost countries. Coupled with the accelerated speed on how things are changing and evolving, employees are suffering from “Future Shock … too much change in too short a period of time.”^[10] By moving to XP or other Agile development methods, one can expect to see the following benefits:^[3]

• Higher productivity and lower costs
• Improved employee engagement and job satisfaction
• Faster time to market
• Higher quality
• Improved stakeholder satisfaction
• What we’ve been doing no longer works