Most meetings so far are in Eindhoven, as mainly represented by the people from the Philips Research Lab. There is also a subgroup that meets in Groningen, as organised by my ex-colleague, Kees Broenink. I have heard that they do occasionally plan meetings in Amsterdam. I’m going to see when that’s going to happen.

I talked about XP and the reasons for it here and here.

What is evolutionary design?

Design is part of the programming processes and as the program evolves the design changes.

Evolutionary design as promoted by extreme programming is a balance between adhoc (no design) programming and planned (one-off) design. It creates the balance by applying the term “iterative” to its fullest potential. The fact is that in software development, the design often evolves as programming is being done. In other words, the “best way of doing things” often evolves as the team learns on the project. There is no way to anticipate all the issues that can come up before you start programming. This is why planned design doesn’t work. If the design is done in a completely separate phase from the implementation, programmers are going to run into shortcomings in the design, and because most programmers are lazy ;), they will just code around it. This means that without the evolution of the design, planned design will dissolve into no design for all the issues that were found after the design was made. This is why the evolution of design should be acticipated and yes, planned.

What enables evolutionary design?
To achieve this, a number of key concepts are used: refactoring, testing, continuous integration. The team must be able to refactor to keep things as simple as possible. Here, the goal is to keep the code as easy to work with as possible. Adding new features should be easy if the framework is the best it can be at that moment. If it is not, then someone should have the vision to refactor the design so it can accommodate the new feature. When refactoring large amounts of code, unit testing and continuous integration are of utmost importance. Refactoring is changing the underlying implementation without changing the functional aspects. Therefore, the unit tests should still work. Maybe they have to be adapted if the API has changed, but functionally, they should still work and the units being tested should still do what they used to do. As soon as unit tests pass, integrate. Continuous integration minimizes the need for merging. And a good test framework makes continuous integration possible. This way you know that what is being checked in doesn’t have stupid mistakes in it that breaks everything. As a result, the code base is as stable as it can be.

Summary
Evolutionary design is about making the best decisions you can based on the knowledge you have at any given time. When design and code are allowed to change, you incrementally achieve the best result because you have a working system at every iteration. To me, this combats the chaos that can ensue when the programming phase reveals design flaws. In fact, extreme programming is not extreme at all. It only takes a wish to work in the most efficient way possible.

Compared to other methodologies, XP is developer-centric and focuses only on the development phase of a project. This makes it easily pluggable into other methodologies such as DSDM and Prince 2. This article explains very well the complementary approaches of XP and DSDM. While XP focuses on programming and relies on the developers for the quality of the code, DSDM advises a clearer application of roles and responsibility. XP also fills in the detail for the development (production) phase within the Prince 2 process.

For me the most notable parts of XP are:

• daily short stand-up meetings
• continuous participation of the customer
• schedule short release cylces in an iterative process
• frequent integration during coding
• focus on testing to proof that the software works

For developers, the hardest part to do is pair programming. The idea here is to raise the productivity of the team by showing the less experienced programmers how it is done. Pair programming during coding allows for constant review on the quality of the code, so bad code is less likely to get into the source base. Finally, how many times have you been searching for a bug for hours until a colleague comes around and spots it right away? In any case, I wouldn’t force pair programming on anyone, but why not give it a try one day a week. Good things just might happen as a result.

Here is another resource for XP:

• XProgramming.com

In my opinion, somebody in every company needs to think about process methodologies, and not just think about it, but be capable and persistent enough to get it adopted and be aware of the need for occasional tweaking of the process when situations change. Because the development process is certainly always going to be a work in progress.