Programmer Practices

Keeping the Code Agile

As the iterations start to flow for a newly-agile team, a new kind of pressure is applied to them. They must deliver working, tested software every two weeks (or three, or four). They find themselves coding more, making more changes to the code, and staying focused on today's deadlines.

Under such production pressures, the team may find they cannot rely on their old programming practices. The programmers and the code itself must become more agile, which is to say, capable of faster change, sooner. Many who have tried working this way would say that this requires not less discipline than traditional programming, but substantially more.

Agile teams have found in practice that agile code is extensible, low-defect code with the simplest robust design that will work for the features currently implemented. It is well-factored and well-protected by unit tests. Among the agile methodologies, Extreme Programming (XP) goes into the most depth concerning how programmers can keep themselves and their code agile. It is increasingly common to find agile teams that have adopted non-XP customer practices but have adopted at least some of the XP programmer practices:

1. Test-first programming (or perhaps Test-Driven Development),
2. Rigorous, regular refactoring,
3. Continuous integration,
4. Simple design,
5. Pair programming,
6. Sharing the codebase between all or most programmers,
7. A single coding standard to which all programmers adhere,
8. A common "war-room" style work area.

Such practices provide the team with a kind of Tai Chi flexibility: a new feature, enhancement, or bug can come at the team from any angle, at any time, without destroying the project, the system, or production rates. We've described the theory and techniques behind some of these practices in articles listed in the Programmer Practices menu to the left.