For many that come briefly into contact with Extreme Programming, it seems that XP calls for the death of software design. Not just is much design activity ridiculed as “Big Up Front Design”, but such design techniques as the UML, flexible frameworks, and even patterns are de-emphasized or downright ignored. In fact XP involves a lot of design, but does it in a different way than established software processes. XP has rejuvenated the notion of evolutionary design with practices that allow evolution to become a viable design strategy. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep a design clean, and how to use patterns in an evolutionary style.

Continuous Integration is a software development practice where each member of a team merges their changes into a codebase together with their colleagues changes at least daily. Each of these integrations is verified by an automated build (including test) to detect integration errors as quickly as possible. Teams find that this approach reduces the risk of delivery delays, reduces the effort of integration, and enables practices that foster a healthy codebase for rapid enhancement with new features.

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of these transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is kept fully working after each refactoring, reducing the chances that a system can get seriously broken during the restructuring.

Many people who work in software development today have heard of the practice of pair programming, yet it still only has patchy adoption in the industry. One reason for its varying acceptance is that its benefits are not immediately obvious, it pays off more in the medium- and long-term. And it's also not as simple as “two people working at a single computer”, so many dismiss it quickly when it feels uncomfortable. However, in our experience, pair programming is vital for collaborative teamwork and high quality software.

In late June over a hundred people gathered on the Mediterranean island of Sardinia to take part in the XP2000 conference to discuss Extreme Programming (XP) and other flexible methodologies.

At the end of May 2002, the XP community once again descended on the Mediterranean island of Sardinia. In this article I look at the plenary speeches from Ken Schwaber, David Parnas, Enrico Zaninotto, Bill Wake, and the Standish Group's Jim Johnson. They lead me into some thoughts on the essence of agile development, the role of mathematical specifications, the complexity of irreversibility, metaphor, and the best way to drastically cut software costs.

One of the attractive things about XP is that it gives quite definite statements about what you should do to be doing XP. Furthermore that set of practices is carefully designed to fit together. Taking anything out has serious consequences. Yet one of the principles of XP and other agile methods is that they be self adaptive: that is you should change the process as you are developing the project. How does this notion fit in with the rigid practices of XP?

When I went to Snowbird in 2001 for the meeting that led to the Manifesto, Jim interviewed me for a book he was working on. It provides a snapshot on my thinking on extreme programming and this thing that a few days later we called agile software development.

An interview done with Pearson to promote our book Planning Extreme Programming. We banter about the background to XP and the role planning plays in an XP project.

Kent Beck came up with his four rules of simple design while he was developing ExtremeProgramming in the late 1990's. I express them like this.

C3 was the short name of the Chrysler Comprehensive Compensation project, a payroll project at Chrysler which has since become famous as the 'birth project' of Extreme Programming.

There are various schemes of Code Ownership that I've come across. I put them into three broad categories:

Here's a common misconception about agile methods. It centers on the way user stories are created and flow through the development activity. The misconception is that the product owner (or business analysts) creates user stories and then put them in front of developers to implement. The notion is that this is a flow from product owner to development, with the product owner responsible for determining what needs to be done and the developers how to do it.

Daniel Terhorst-North's recent blog post on software craftsmanship has unleashed a lot of blog discussions (which I summarize below, if you're interested). There's a lot in there, but one of his themes particularly resonated with me, hence this post.

Extreme Programming (XP) is a software development methodology developed primarily by Kent Beck. XP was one of the first agile methods, indeed XP was the dominant agile method in the late 90s and early 00s before Scrum became dominant as the noughties passed. Many people (including myself) consider XP to be the primary catalyst that got attention to agile methods, and superior to Scrum as a base for starting out in agile development.

On-site customer is one of the practices of extreme programming, one of the twelve mentioned in the White Book. It says that a customer should sit with the developers in their open work area to be available to answer questions and interact with the development team. Indeed they are part of the development team, and recognize that the success of the team depends as much on them as it does on the developers. They don't have to give up their reqular job to do this, but they must be physically present.

Pair Programming is a software development practice that has the developers work in groups of two. All serious code is written by two programmers, typically sitting side-by-side with a single monitor, often with a single keyboard. As they add code, they discuss each step together.

A bunch of common misconceptions about Pair Programming.

Every XP aficionado knows about the 4 values and 12 practices, but how many people know about the 15 principles? I'll confess I didn't when Kent talked about them at JAOO last week. After the talk I asked Kent about them: “were they in the White Book“. “Yes”, he replied, “cunningly hidden in a chapter called 'Basic Principles'”.

Self-Testing Code is the name I used in Refactoring to refer to the practice of writing comprehensive automated tests in conjunction with the functional software. When done well this allows you to invoke a single command that executes the tests - and you are confident that these tests will illuminate any bugs hiding in your code.

Unit testing is often talked about in software development, and is a term that I've been familiar with during my whole time writing programs. Like most software development terminology, however, it's very ill-defined, and I see confusion can often occur when people think that it's more tightly defined than it actually is.

When people talk about Extreme Programming, they often focus on such things as its adaptive planning style, or its evolutionary approach design. One small but growing trend that particularly interests me is the small but growing number of XP projects that have very low defect rates, by which I mean less than one production bug per month.

Velocity is a notion that helps calibrate a plan by tying broad statements of effort into elapsed time. Velocity is a statement of how much stuff a team (or a person if it's personal velocity) gets done in a time period. You should usually determine velocity by measuring how much got done in past periods, following the principle of YesterdaysWeather. A typical approach is to average the velocity the past three time periods to determine velocity for future time periods. Velocity was originally formed as part ExtremeProgramming but has since spread and is now used widely in agile software development of all flavors.

This is the principle that says you'll get as much done today as you got done yesterday. In iterative projects it says that you should plan to do as much this iteration as you did last iteration. The term comes from the Extreme Programming community.