Many of our customers are interested in agile methodologies. Here's a follow-on to our post about lean software development.
Extreme programming (XP), a subgroup of the Agile programming methodology, emphasizes customer satisfaction by taking the voice of the consumer into account and improving overall quality. Like other processes within the Agile Development discipline, XP emphasizes short cycles of development and frequent software releases.
Kent Beck, one of the key developers of Agile programming who has also co-written a book on extreme programming said “The basic advantage of XP is that the whole process is visible and accountable. The developers will make concrete commitments about what they will accomplish, show concrete progress in the form of deployable software, and when a milestone is reached they will describe exactly what they did and how and why that differed from the plan. This allows business-oriented people to make their own business commitments with confidence, to take advantage of opportunities as they arise, and eliminate dead-ends quickly and cheaply.”
The extreme programming methodology is designed to take the best aspects of traditional software development to extreme levels. When it comes to programming, it basically involves breaking up a coding project into small tasks that are simple enough to code, developing into a series of modules that need to be designed and created.
This speeds up the software development cycle, lowers the error rate, and gives everyone involved a clear map of their collective progress. Some third-party programs, such as Airbrake, are offering their own error-catching and reducing services.
So, what exactly makes Extreme programming so special?
The Core Practices of Extreme Programming
There are 12 practices, known as XpXtudes, organized into four general themes.
Fine Scale Feedback– Consists of the practices of Test Driven Development, the Planning Game, Whole Team, and Pair Programming.
Test Driven Development refers to the constant testing of code as it is being written. The general principle is to write enough code to just fail a test, and then finish the code to pass the test. Next, remove duplicate processes within the code.
The Planning Game consists of creating some emotional distance from the software development planning process by playing a game with it. It basically consists of creating pieces, called User Stories, which have their own value and cost. The goal is put the most total value into production at the lowest cost.
Whole Team simply refers to getting as many developers working into one room as possible.
Pair Programming refers to having two programmers work on the same program at once, on the same station. This lets them each be responsible for one aspect of the Extreme programming method – one person works on the test, and the other can think about a program to pass the test.
Continuous Processing (as opposed to batch) – this consists of the principles of Continuous Integration, Design Improvement, and Small Releases.
Continuous Integration means that whenever an individual developer improves the code, they send that improvement to the other people working on the project. Systems are designed to be able to quickly share code improvements between team members.
Design Improvement refers to the continuous awareness that, at any time, the overall design of the project might be enhanced in some way.
Small Releases maintain a quick coding cycle, in which each code module has only a small function.
Shared Understanding – within this category are Simple Design, System Metaphor, Collective Code Ownership, and Coding Standard.
Simple Design means not coding anything that does not have business value.
System Metaphor refers to creating a simple story to describe the architecture of a coding project and provide suitable labels.
Collective Code Ownership is a perspective that the code being developed belongs to the entire project, rather than individual developers.
Coding Standard means that people prefer to program in different ways, and a team needs to choose a standard way to code. This includes how to name things, whether or not to indent, and bracket locations.
Programming Welfare – this category contains the principle of Sustainable Pace.
Sustainable Pace refers to giving programmers the time and space they need to work well. It means that productivity does not necessarily increase by increasing the number of hours worked per week, and it gives developers a chance to relax and actually have a life. A well-fed, well-rested programmer will work more efficiently with fewer errors than a tired programmer waiting to go home.
