I remember years ago when I first heard about eXtreme programming and my only thought was that I preferred it's branding than Waterfall's.

I started to hear work collegues around me wanting to adopt some of the principles. Such as code reviews, increasing communication with stakeholders and the introduction of short sprints.

All of this wanting came from a good place, but unfortunately a lot of people felt that taking the entire XP principles wouldn't work on a larger scale. I'm starting to believe that it wasn't that XP doesn't work in large scale, perhaps it's that XP require a certain company culture.

Pair programming requires developers with good communication skills, team players and a certain amount of discipline. One of the beneifit of pair programming is that it's a form of continious code review, which I'm confident leads to increased code quality.

Another tenent of XP is uniti testing of all code. When I first heard this idea years ago I initially thought that can't be possible on a large scale system. How would one write all those tests and still ship the software before the sun burns out? That's where Test Driven Development comes in.

By now TDD to me is second nature to me. I incredibly uncofortable when a feature hasn't got an associated test, or when I see a developer writing code without first writing a test. However years ago, it made sense to me to write the test afterwards, or worse, no test at all because it's a simple feature and what could possibly go wrong?? right?

These were my early thoughts on Xp, I'm happy to say I know more now and appreciate the various values of XP, and will be talking about it some more in future posts.

Ced