Many of the practices that make agile programming such a high-performance method for software development often stem from ideas that, at least initially, seem counter-intuitive. One of the most common criticisms of agile programming, for instance, is that it is a discipline that eschews planning. This argument, of course, is a response to agile’s departure from waterfall’s exhaustive emphasis on upfront requirements gathering. In agile programming, defining requirements occurs over the course of a project: As more information is gathered, more requirements are added. Furthermore, this practice eliminates the chances of teams wasting weeks or even months speculating about what features should be built into a product.
Another agile practice that might seem similarly unorthodox is pair programming. Pair programming is a development technique in which two developers sit side-by-side at the same monitor and code together: the “driver” writes the code, while the “navigator” reviews it. The two developers trade roles frequently throughout the process.
So why should two programmers do the work of one? Well, where two individuals working independently might yield more code (i.e. quantity), the pair programming scenario preserves the quality of the code. Because code must be acceptable to both programmers to proceed, this ensures that the pair discusses alternatives and, typically, settles on a simple, maintainable solution. But the advantages don’t end there. The pair also ends up exchanging knowledge and skills through hands-on collaboration. And given that fixing bugs can be one of the most expensive aspects of development, this attention to code quality can help save money and time by investing in quality assurance throughout the development lifecycle.