thoughts.on.code

I’ve been thinking alot about Agile Development (AD) since getting back from NFJS. Listening to Venkat Subramaniam talk about Test First programming and AD has rekindled a desire to express myself in the medium of bits and bytes.

I have been following the AD movement since eXtreme Programming eXplained came out. At the time, I thought the concept was awesome, but not very practical - it seemed like a mountain would need to be move to convince my team that this was a better way. But, one of the nice things about AD is that you can do most of it by yourself. So, lets see how I compare:

Testing:
I have always done programmatic testing (except for a few bleak years where I dealt with PROCEDURE DIVISION statements all day), though I had a tendancy to toss the code after the test. Don’t ask me why. It just didn’t click that “Hey… all this can be reran to ensure the correctness of the code!”. Every once in a while I would find a useful test program for things like JSSE code, and would move them to a directory, usually never to be used again.
I think that very rarely has testing driven any aspect of my designs though… I’ve always had an idea of what I wanted, then coded the test to work with it.

Pair Programming:
Most code that I have written has been alone, usually late at night. However, I have worked as part of a pair before, and would say that the code written by two people is almost always better than that written by the solitary coder. Recently Kyle and I sat down for a day and refactored that JSF application I just blogged about to get rid of IBM’s insidious “codepage” from inbetween our Managed beans. I would say that the two of working side by side on that made us a lot more productive then if we had each just taken parts and worked on them seperately. By “more productive” I am really saying that together we produced fewer errors, and were able to talk through the problems at hand an come up with a more elegant solution together.

User Stories / Planning Game
I have never done anything like this, and am very interested to see how it works. I have only witnessed the “upfront” planning style, with little to no pushback allowed from the developers end as far as dates/features went. I have always disliked this, but have not found the voice to say that there is a better way, mainly because I do not “know” any other way.

There are obviously other tenets to XP, and Agile Development in general. The three above are the ones I am most familiar with. I think the most important tenet for me right now is the concept of Test First Development, which, in my mind, is a more disciplened version of Test Driven Development. You write out every test before you write the code, even the method signature!

So, I have volunteered to speak at the next OJUG meeting regarding Agile Develpoment… kindof a intro to Agile, with a more indepth look at TFD. I am starting out in Venkat’s foot steps: I’ve written, test first, a Peg Game engine. I’ve mentioned this game at least a couple of times on my site, and most people who know me have probably seen a printout of a solution to the game from a solver I wrote many years ago. I still have this code, but forced myself to stay away from it… knowing the terrible path that lies there.

I’ve written the engine, and now am trying to put together a paper/presentation the steps and missteps I took while writing it. One thing I can say for sure is that I am much happier with the code this time around. I think the main reason for that is that I’ve written it for general purpose use… it is no longer a Game Theory model for a recursive solver program, though it could be used for that (and knowing my fascination with this game, it probably will sooner or later).