In a mirror, dimly

I recently got some code from an old friend / coworker of mine. It’s a project that he’d been working on outside of work, still not ready for the prime time and as yet, the project didnt even have a name. I know he’d been working on it a while and I was fairly excited about seeing the results. Anyone that knows me knows that I like to build software from its source, rather than use something pre-built. I also dont want to fight with something to make it work either! In the case of my friend’s project he didnt have a make file, or a build.xml or anything. First hurdle: how was I going to build the code and try it out?

It didnt take long to have an ant build running. I have a standard build.xml file that does all of the basic compile / run / clean / distribute kind of steps that all I need to is edit properties specific to the project at hand. This build file has evolved from one project to the next. Its simple, does what I want, and takes me about 5 minutes to bring a new project up to speed with a clean build environment if I need it. Plus, it gives other people a single point of entry if they want to look at my source and build a working application. I highly reccommend creating a single automated build script!

Building the code was interesting, thanks to JDK 1.4 and 1.3.1 differences. He’s using JDK 1.4. I think it took about an hour to spin around the code commenting out the pieces that broke on my computer. One positive thing I will say about his code is that he’s isolated most of those 1.3.1 / 1.4 differences in a single file. All I need to do is find out how I can code a work around and swap that file out. I’m thinking that there must be a way, through dynamic class loading, to do this. I’ll post it later if I come up with a plan.

Getting the right batik libraries was another bump in the road to seeing his application running. This was the feature that he has most been proud of: the application could display text, HTML and SVG images. I want to try runnning the batik code on my machine: folks in work have commented that it is memory hungry. Anyone have that experience?

The final experience in the application was pretty much what I expected though there was a feeling of being let down. I know he’d worked hard on it and poured himself into the project. What I was seeing didnt seem to reflect the amount of effort somehow. I know his output on our team was higher than this when we worked together. I found out what happened when I took a look at the code and I realized that my own software design paradigm had shifted over the last six months. He’d complained to me that he felt the code was hard to follow and I agree having seen it. The problem is how to put into words what I saw?

Pair Programming

Pair programming seems absolutely nonsensical when you first look at it: two programmers expected to share a single computer and still get the job done? In practice though it appears to work better than a single programmer on their own. Everyone gets tired. Everyone gets distracted. Wouldn’t it be nice at that point if you could switch out to your spare brain, or have your spare arm tap you on the shoulder and spare mouth tell you that you maybe ought to be working?

In previous projects I’ve ended up bogged down in a problem. Worse still I have had meetings to attend and people coming to my cube to ask me questions while I was bogged down. I experienced non-maskable interrupts, breaking me out of the stack of other interruptions stacked several deep. When thinking of working from home people joke about whether they should work a full 8 hours at home or the actual productive 2 hours that would have been spent had they been in the office. “Many a true word is spoken in jest” so they say, and pair programming might just turn out to be that kind of joke!

My experience to date has been one of intensity, of my pair “keeping me honest” with regard to use of time, of wide ranging discussions during compilations and while tests were being run, of a general emotional demand from all the interpersonal interactions and yet a deep and abiding sense of satisfaction in a job well done and fun while doing it. Because 2 sets of eyes have looked at code, and two brains have chewed on the problem, quality of output is unsurpassed. Combine this practice with test-first development and you truly have a winner. Now to eradicate lengthy meetings and the constant paper chase of corporate life.

Interesting things I should have been blogging about

• XP STL
• Alpha
• Releasing source code

XP STL - the eXtreme Programming group in St Louis - meets the first wednesday of the month. Last night was the official February get together with Kyle Cordes speaking about the concept of “once and only once” - avoiding duplication in Java code. Highly informative and the presentation is going to be on the web soon: I’ll link it when it comes available. Im thinking that I should present something and talk but as yet cant decide what I would talk about.

Interestingly, Alpha is all about me (as a leader) not talking! Its a lot of fun starting the ball rolling and keeping the momentum of the conversation going, but, its also highly tempting to speak at length myelf. Thing is, Alpha isnt about being preached at and having ideas force-fed, it’s about a safe place to process you spiritual stuff and investigate the claims of Jesus. This week saw the first meeting and all I can say right now is that they are a divese bunch! Im really excited as to where things go from here.

Last but not least, I’ve released the source for a pure Java implementation of the RSS specification. It was written entirely test-first, with automated jUnit tests capturing and enforcing standards compliance. This is the first release and obviously there will be things folks dont like but I will go out on a limb and say that the implementation is virtually bug free thanks to the quality that comes from test driven development methodologies. Please download the code and let me know what you think. Remember though: it’s a library and aims to support another application. There’s no GUI (yet).