Often designs techniques are used to make a system more flexible, but end up being harder to work with. One of the reasons is that explicitness is a property that often gets forgotten in design.

Thinking about how to visualize and reduce coupling.

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.

Craig's spot in the column looks at the importance of the Open-Closed principle and Protected Variation, and why Parnas's information hiding is more than encapsulation. He also gives some tips on ways to implement a protected variation.

One of the first lessons I learned was to always keep user interface code separate from anything else. Not just is this still good advice, it's surprising how often it's forgotten.

In January 2001 two Java tools crossed Refactoring's Rubicon. Refactoring in Java now has serious tool support

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.

A group of seventeen people got together in Snowbird, UT in February 2001 to talk about new styles of lightweight methods. One result of this is coining the word agile to represent a new breed of agile processes for software development. We also put together a Manifesto for Agile Software Development which describes the values and principles of these agile methods. Jim Highsmith and I wrote this article for Software Development magazine to further explain the manifesto.

It's sometimes quite remarkable how the simple rule of avoiding repetition in software can lead into good design

Since the begining of the new millenium, we've been running an interesting XP project. It's interesting not just because it was one of the first XP projects at Thoughtworks, but also due to its size: around 50 people are involved. Here we talk about how we run this project by focusing around the activities that need to be done for a single iteration, and how the various subteams work around that iteration.

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?