Development the XP Way

So I mentioned last time the principles that XP brings to software development specifically the ways in which developers approach working on an application. If there's an overarching, elevator pitch statement about XP, I would put it as this:

XP (and Agile in general) focuses on delivering known value today rather than rumored value tomorrow.

The trick is how developers can accomodate the fast turnarounds of small chunks of functionality that need to work (and work well) vs just be at some random level of completion. Gone are the lengthy amounts of time spent doing exhaustive analysis and design, test cycles, and so on at distinct phases of a development lifecycle. They are replaced by doing many of these things simultaneously.

By observing what is good in software development (or maybe better put as what works), Kent Beck came up with some (paraphrased) observations:

If testing is a good thing, then test all the time.

If integrating code is a good thing, then integrate continuously.

If simplifying code is a good thing, then re-factor it all the time.

If working together to implement a solution is a good thing, then work together all the time.

Testing all the time means that we focus on treating tests as co-equal to the code. They are not things that we write haphazardly at the end, or not at all. Tests are written up front before the code is actually written. Code is not assumed to be working until the tests pass. As code is changed, tests are constantly re-executed checking for problems.

Integration all the time means that we focus on building the entire application at least daily and preferably whenever a code check-in is performed by a developer. Constant integration ensures we know immediately if there are code units which have changes which have broken other parts of the system. Ideally, integration is done automatically by a centralized build machine without developer intervention.

Simplifying (refactoring) code all the time means that developers are looking for ways to remove code, not just add it as features are developed. A corollary to this is that removing code should be done all the time. Most systems have huge amounts of seldom-used code that can be refactored to do the same with less effort. The key is to have a robust set of tests to ensure the refactoring doesn't change the semantics of the code.

Working together all the time means that developers pair up to write code rather than once in a while. This includes everything around writing code including data design and architecture. This also has the added benefit of spreading the knowledge around so the team isn't dependent on any one developer exclusively.

Particularly if you are working on a new project, the XP model for software development is very attractive. Software gets built faster with more focus on the items most relevant to the customer and with more reliability. The challenge of course, is what to do when you're working on projects which are pre-existing, have no body of unit tests, are under constant time pressure, knowledge is in silos, the team is distributed, and so on.

For the answer to that, next time I'll explain why I chose Scrum rather than pure XP as my initial Agile software development model.

Technorati Profile

Posted by Mark M. Baker at 04:33 PM  Permalink