Introduction

I gave a presentation (of the same title) as part of CodeGear's CodeRage07 this week. The general purpose of the presentation was to encourage people working in Delphi to adopt Extreme Programming practices. Even if you're in a situation where getting buy in to process changes is difficult, I'd encourage you consider each of the XP practices on its own merit. It is not dogma if it makes sense and is a better way to do develop software, which I believe each of these practices are.

 

In the presentation, I discussed many of the XP practices that are the same no matter what language you use primarily. However, I did really try to make a point of showing tools to use along with Delphi and showing some TDD techniques with Delphi (including Presenter-first style MVP).

In this article, I'm not going to repeat the entire presentation, but I will go over some of the highlights. I will be sure to add a few notes that I forgot in the presentation and I will include a link to download the Delphi source from the code example in the presentation.

Core Values

Primarily from XP Explained (1st Edition), communication, simplicity, feedback, and courage are the core values behind XP. We need to be disciplined in our efforts to develop software and having these values aid in making everyday decisions. Along with these, there going to be challenges. Especially related to courage and discipline, consider the following:

 

• Try writing all of your tests first.
• Try writing your acceptance tests first.
• Try minimizing your use of the debugger.

In Delphi, we focus on things like rapid feedback with DUnit; we do our best to defer complexity until it's really necessary; and we strongly believe that big changes all at once are ineffective and error prone, which is why we tend to work on small units of work and checkin early and often to SubVersion. We especially embrace changes in requirements, changes in database structure, changes in design, etc. There are no "freezes" in our environment.

Finally, it's all about quality. Ultimately, the buck stops at the customer (or customer advocate such as a product manager), but everyone is happier when quality is higher. In this sense, quality is not truly a variable that can be compromised. I highly recommend everyone track 1 or 2 quality metrics in order to ensure a focus on quality. For us, it's bugs/developer-month, but simply keep an honest measure of yourself.

Continued...