Setting the Bar for Technical Excellence â€" Developer Practices
Technical excellence is at the heart of Agile processes. In order for the other practices to really be effective, we must cultivate technical excellence in developers. At the face of it, technical excellence may not seem a core priority, but by focusing on this, it gives us the confidence we are writing exceptional code. This in turn gives the business, customers, and users the same confidence in the software and our ability to deliver.

The developer practices are concrete ways we can drive technical excellence. Even done in isolation, without other Agile practices, the developer practices can give you significant gains in software quality.

The developer practices breakdown into four (five if you include actual coding) practices. These are the Test-Code-Refactor cycle, Pair Programming and Simple Design.

Test-Code-Refactor (TCR) Cycle â€" Step 1
Often shown as separate practices, test driven development and refactoring are really part of the TCR cycle. To create the tight feedback loop we are after, we need to put them together.

Our objective here is two fold; tests give us confidence in the code's quality and show we aren't breaking anything as we add in new code; refactoring and tests help make the code the truest form of communication of what the code is actually doing â€" anyone should be able to see it and know what is what.

TDD (or test driven development) is a cycle that starts with a failing test, implements just enough code to make the test pass and then refactors the code to make it as simple as possible for the current functionality of the system.

The test-code-refactor cycle is very short â€" in the order of minutes. Anything longer is an indication that the tests are at too high a level and chances are there is untested implementation code being added.

Rather than walk through a TDD example from the beginning, which is well covered elsewhere^{2, 3, 4}, it would be useful to take a whole story and highlight some of the more interesting aspects of the TCR cycle.

As with any Extreme Programming/Agile project the first story is a simplified version of the application demonstrating the functionality end to end. In this case the application is an implementation of the card game Blackjack. In the simplified first story there will only be one player and the dealer, only two cards will be dealt to each player and the winner will be the highest hand after the two cards have been dealt.

Story/Requirement
Play a simple game of blackjack

• Player places bet
• Deal player & dealer 2 cards each
• Pay winner (player odds 2:1)

Acceptance Tests
To know when our story is complete we need a set of acceptance tests. The acceptance tests for our simple game are as follows.

Player Wins	Dealer Wins	Draw
Player pot = 100	Player pot = 100	Player pot = 100
Dealer pot = 1000	Dealer pot = 1000	Dealer pot = 1000
Player bet 10	Player bet 10	Player bet 10
Player dealt 10 & 9	Player dealt 8 & 9	Player dealt 8 & 9
Dealer dealt 8 & 9	Dealer dealt 10 & 9	Dealer dealt 8 & 9
Player pot = 110	Player pot = 90	Player pot = 100
Dealer pot = 990	Dealer pot = 1010	Dealer pot = 1000