Tuesday, June 1, 2004

Why I love Extreme Programming

Extreme programming (XP) is very “now” focused, intending quick deliverables and discounting most future business planning as too uncertain to be relied upon. Extreme programmers value the simplest, most modular and re-purposable solution as the best. Yes, there is a risk that a future project might therefore require more resources than it otherwise might if the system had been built with the future plans in mind; but most XP afficionados argue that this is more than compensated for by not investing in things that never get done or have to be completely changed. An XP programmer can work with *only* unit tests and an integration test. There are no specs, aside from the detailed unit tests. However, the unit tests are written in excruciating detail and success criteria are strict so there is honestly no need for specs – a skilled client can easily define unit tests. The ‘specs’ are therefore only the list of what changes from the previous set of unit tests and integration tests need to occur, with an understanding that the unmodified test cases still have to work in the future.

Extreme programming is a type of Agile programming. Others are Scrum and Crystal. The biggest advantage of agile is the mandate to continually refactor the code; even if there is no present business requirement, developers are tasked with breaking down the codebase to make it more variable-driven and flexible using the pricipals of object-oriented programming.

The opposite of Agile is waterfall methodology. The antithesis of either is “cowboy coding” or, basically, no methodology at all.