Two bugs in two years, new features every week, deadlines met each and every time and whats with these ruby slippers?
It's been just under a year now since I started practicing XP programming, and I have to admit, as much as it is anathema to my style of programming, it is a flawless system that far surpasses the wildest dreams of my programming expectations.
Before I begun on this Odyssey I had a fairly standard view of programming. I was a good programmer; I knew my stuff and was more than willing to learn anything I didn't. I was comfortable with a fairly heavy workload, with a few late debugging nights a month, a minor bug or ten in a production release, and deadlines conveniently padded on either side with big fluffy cushions and a pager on my belt, just in case.
I wasn' happy, of course, slipping deadlines, or finding my carefully written code has obscure bugs when twisted by the users in the wrong direction or getting beeped just as I relaxed into bed, but I was never really particularly upset. These things just happen, and eventually they would be righted, even if it took a weekend coming into the office or a late night phone call to India.
In every sense of the word, I was a typical programmer, and I enjoyed it. But then, one cold winter day in land of the rising sun, I took a step down a road that would change my view of the programming lifestyle forever.
The first thing our chief architect, and my new mentor, told me flat out was: XP is dangerous; you either do it the right way and become wildly productive or you leave out a facet and become a dismal failure. So in that vein, the XP we have been practicing is 100% by the book, to levels that even the experts rarely advocate. 100% pair programming, 100% test coverage (well, test driven development, that is nothing, and that means nothing, gets written without writing the test first), such aggressive refactoring that, when duplicate or suspicious code is found, all other considerations are dropped until it has been dealt with. The cases and rules go on and on, all knobs turned up to eleven.
For a free spirited programmer like myself, and one who really enjoys the mental thrill of solving a complex problem in an interesting and equally complex way, this style of programming was anathema. It's tedious and dull most of the time when your head is still in the old programming world. Indeed, interesting code is usually the very first thing to get refactored out, to be replaced with very simple, very straightforward approaches that any junior programmer can understand.
For the better part of the first half year I was following these principles while still taking my proverbial grain of salt. I would follow the practices as I had a certain amount of respect for the leader of the system, but I was always on the lookout for the fatal flaw.
Well, as the year passes, the fatal flaw was still unfound, but what I did discover was that many of the precepts that I had taken for granted in software engineering were fallacies themselves. Bugs were NOT the nature of the beast. Indeed, even bugs that rarely found their way into non-production code (those committed to cvs by a sleepy programmer before heading home, for example) were considered absolutely critical, and were instantly dealt with. Indeed, in over two years of XP (of which I only could see half) there have been only two actual bugs make it into production code, and both of them were due to very specific requests by our clients who were asking for behavior that they didn't really want, but didn't realize that until after we provided it to them.
But despite our pristine, bug-free, code, we do not rest on our laurels. Release schedules of six, or even three months, something that I previously would have considered quite prudent, are laughable now. It is a rare week that we do not introduce new, fully tested features to our clients.
Overall, I have found XP to be a system that really does deliver, and in a big way, albeit with a great deal of "getting used to" by everyone involved. Unfortunately, I can see many areas where it will fail if it is not followed closely, and without dedication, which means it is very hard to attempt in any sort of "trial basis", or attempt to implement in bits and pieces.
Indeed, if anything, that I believe is its major flaw. In everything it is extreme, including its adoption. If you don't jump in the deep end, you will most likely fail to see its benefits. It really is a pity, because I don't think I can go back to my old style of programming now, but I also think there will be very few willing to partake in the total dedication required to make it successful.