Extreme Programming (XP) Coding/Technical Practices

Pair Programming

Pair Programming is a highly collaborative coding practice whereby a single development is undertaken by two people at a single workstation. During the execution of a Pair Programming development, the first developer (known as the driver) has control over the workstation and focuses on the coding in detail. The other developer (known as the navigator), sits directly next to the driver, and continually reviews the code that is being produced, as well as considers the bigger picture.

Benefits of Pair Programming include:

• The pair keep each other focused on the task;
• The driver has ability to immediately clarify and/or brainstorm ideas (ultra quick feedback loops);
• The driver experiences less frustration whilst coding because the navigator can assist (or take over) if/when the driver partner is stuck;
• The pair can enforce good habits on one another and hold each other accountable to the team’s XP practices;
• Communication and collaboration is enhanced as the pair share knowledge, experience and ideas.

Click for more information about: Pair Programming.

Test Driven Development

Test Driven Development (TDD) is a XP practice whereby the programming cycle starts with writing a test that fails! Tests are written for small pieces of code which can be tested independently (very succinctly). Tests are written, ran and failed… then and only then… is the code written to make the test pass! The code is then refactored and the tests are automated (and ran ongoing). The cycle then repeats itself. Tests are kept very small, the cycles are kept very tight and a rhythm is generated.

Benefits of TDD include:

• Minimal upfront design is required and the practice assists the XP developer and team evolve the design over time.
• Debugging time is reduced as less time occurs between introducing a defect and identifying it.
• The tight test-code cycle creates a lot of feedback loops.
• A comprehensive (automated) test suite, that checks the core behaviour of the code, is created from the outset.

Furthermore Kent Beck highlighted the following problems are addressed by TDD:

• Scope creep is controlled because the developer explicitly/ objectively states (and therefore focuses) on what the program is supposed to do in a small, concise test.
• Decoupling from design is reduced because if its hard for a developer to write a test, it’s a signal of a design problem. Loosely coupled, highly cohesive code is easy to test.
• Low confidence/trust in code and developers is managed through clean code that works (and demonstrated with automated tests).
• Loss of focus is avoided (developers getting lost in the code for hours) because TDD makes it clearer what to do next: either write another test or make the broken test work. With small test-code cycles this focus develops into a natural and efficient rhythm of test, code, refactor, test, code, refactor.

Click for more information about: Test Driven Development.

Simple Code and Design

Keep it simple! XP suggests that when designing and coding, focus on the current requirement only, and do not attempt to address future/potential requirements.

XP uses a number of catchphrases that remind the XP developer to focus on flexibility through simplicity. These catchphrases are:

1. Do the Simplest Thing that Could Possibly Work;
2. You Aren’t Gonna Need It;
3. Once and Only Once.

Incremental Design

The XP practice of designing incrementally suggests that the optimum time to undertake design is in the light of experience. Therefore when the XP team’s understanding of the best possible design emerges (in light of experience), they must work gradually but persistently to bring the design back into alignment with their developing understanding.

The practice of incremental design is heavily facilitated by other XP practices that make it possible for XP teams to be able to adapt the current design to future requirements. ELABORATE HERE?!???!?!?!?!??!

Refactoring

Refactoring is the XP practice of restructuring existing code without changing it’s external behaviour, with the intention of improving nonfunctional attributes of the code such as reduced complexity, improved readability and improved maintainability.

In the normal process of software development, the code gradually/naturally becomes more and more complex due to developers having to integrate each of their new tasks with previous code. However, whilst undertaking the integration, XP encourages the developer to update the initial code to reduce complexity (rather than increase it) with every change.

Refactoring in XP makes the code simple as possible to find defects, and make further change easy to undertake, which is particularly important in Agile delivery due to the emphasis on flexibility in delivery. If the customer wants to change something in the final product, having simple code that is easy to update will assist in making changes as soon as it is possible.

XP emphasises that the process of refactoring must be constant (and incorporated into tight test-code feedback loops).

Benefits of Refactoring include:

• XXX
• YYY
• ZZZ

The process for Refactoring is as follows:

1. Identify a working test for the feature/code that is about to be refactored. This is an important part of the XP refactoring process because XXXXXX shouldn’t change XXXXX;
2. Undertake refactoring or a section of the refactoring; simplify and/or improve the code;
3. Test the unit that was refactored to ensure nothing has broken;
4. Repeat steps 2 to 4 for the other sections of feature/code being refactored.

Code and Test

XP suggest that only the code and the tests should be maintained as permanent artefacts. This closely complement’s the Agile Manifesto statement of “Working software over comprehensive documentation”.

Other documents, if required, should be generated from the code and tests and social mechanisms (rather than archived documents/assets) should be used to maintain awareness of the important history of the project.

Coding Standards

Coding Standards are a practice whereby the team define a programming style that they all follow. They are a set of rules and guidelines for the formatting of code which the entire team follows when writing, reading and also refactoring.

Benefits of Coding Standards include:

• The code will be will be easier to maintain as all the development team are familiar with the coding style regardless of whether they were the original author or not.
• Communication efficiencies as less hand-offs are required between the development team and operational or governance areas within the organisation because details of the specification are in the coding standards. Likewise communication between the team members become more focused and efficient.
• Code that is consistent and recognisable to all team members encourages Collective Ownership.

Common Vocabulary

XP suggests that the development team should develop a Common Vocabulary to describe the each components in the product/project delivery.

Collective Code Ownership

The XP practice of Collective Code Ownership, where the entire team is responsible for all of the code, facilitates teamwork, colloboration, empowerment, refactoring, and more.

In Collective Code Ownership, all developers on the team work together to produce a product of quality and no one individual developer is greater than the rest of the development team members.

Benefits of Collective Code Ownership include:

• Facilitation of knowledge sharing becuase collective responsibility for the code results in all the team learning about all of the code. This in turn, has a postive impact on product quality as increased capability results in more opportunities for enhancement (including through the process of refactoring).
• Increased levels of code quality and improved coding style as team members challenge one anothers coding (including during the practices of Pair Programming and Refactoring) and enforce good habits on each other. No one individuals coding style dominates the product code or area of product code.
• Reduction in single points of failure becyuase no one person exclusively understands the code or particular area of code.
• Increased effectiveness around code reviews becuase the reviewer is more familiar with the collective code and coding style. Therefore reviews become more efficient and effective which subsequently results in reduction of defects/errors and surfacting of different ideas and improvements.

Click for more information about: Collective Code Ownership.