13 November 2007

ANN: Agile Ottawa Event with Mike Milinkovich

The Agile Ottawa group is pleased to announce a special meeting featuring Mike Milinkovich, the Executive Director of the Eclipse Foundation.

When: Wednesday, December 5th at 7:00 PM

Where: The "Theater" at BitHeads, 1309 Carling Ave. (Westgate Mall),
at the entrance on the East side of the building

What: "How Eclipse Does It"

Abstract: The Eclipse community has a truly enviable track record of shipping high-quality software releases on schedule. For the past five years, the Eclipse open source community has hit its release dates. And it does this in an environment that involves contributions from many different organizations from around the world. How does Eclipse do it?

If you or your organization deals with large-scale and/or distributed development and still want to be agile, this talk is for you! Please spread the word around to anyone you feel would be interested.

The venue has seating for approximately 80 people, but please RSVP to me anyway so that we have an idea of the number of attendees to expect.

See you then!

7 November 2007

Simple Design Illustrated

I've been asked quite a number of times about the agile principle of Simplicity and the associated XP practice of Simple Design in XP. People ask, "What is simple?" I suppose it's all quite subjective and relative and contextual. This week, however, I endured a rather stark lesson about simplicity myself! I've been at this software development gig for 20 years professionally now, and I'm pretty good at it. I've learned quite a bit about relational and object modeling over the years, and I leveraged my knowledge and experience when designing the persistence mechanism for a system on which I'm working.

Initially, I did the simplest thing that could possibly work, and simply wrote and read serialized Java classes to and from disk. This worked fine, but the Customer for the system needs to be able to track relatively detailed metrics about the system's usage, which was difficult at best with the "simple" solution.

So, I thought, we're going to need to persist this information to a database!! Suddenly, simple serialized Java classes became Hibernate configuration Hell between two independent classes with a many-to-many relationship. I figured that I was just scaling more of the ORM learning cliff when I simply couldn't get the association to work - it was griping about duplicate keys in an association table. After a couple of days of assuming it was my fault, I discovered that there was a bug in Hibernate that created a unique key where it had no business creating one. Removing that key made everything work... at least in my tests.

Ah yes, the differences between tests and the real, integrated application. The bar may have been green, but the application would still barf at times with issues about the Hibernate session having more than one instance... blah... blah... blah... I'll skip the rest of the gory details. In the end, I had spent about 2 calendar weeks working part-time on implementing this solution, and it still wasn't working. I was (and still am) frustrated, and kept saying to myself that it just shouldn't be that difficult.

In the shower yesterday morning, feeling rather defeated, I stepped back (figuratively - it's a small shower stall!) from the situation and asked myself what the Customer really needed. They needed to track activity and run reports. I thought about what activities were to be tracked, and realized that it all fit very nicely into a single table.

I finished up in the shower, and 1.5 hours later had the single-table-based solution working, tests included. It still has serialized Java classes for some data, although those will likely become XML-based quite soon (using XStream, which appears to be very simple!).

So, I had spent about 20 hours trying to implement the "standard" solution, and it never worked properly. I spent 1.5 hours on a much, much simpler solution that does everything that the Customer requires, and it's in production as of 9:30 PM tonight.

In a nutshell, my 20 years of experience using traditional techniques and assumptions came back to bite me on the backside. And that, my friends, is tonight's lesson in Simplicity and Simple Design. I just wish I had learned it a couple of weeks earlier!

5 November 2007

The Perils of Working at Home (...or No Good Deed Goes Unpunished!)

I'm working at home today. Yes, I'm really working. I like working here - it's a quiet or loud as I want, I don't have to shave, and I can wear sweatpants all day if I like!

An added benefit is that I can get a few things done during "down time", which would be those moments of chit-chat if I were in the office. Today, for example, I decided to do some laundry. I tossed in a load right before a 1:00 PM conference call, and by the time the call was done so was the washer. Great, I thought, I'll quickly fold what's in the dryer and throw in the load from the washer.

Not so fast!

When I entered the laundry room, I discovered that the laundry tub was quite full of water that had drained from the washer. Um, that's not supposed to happen! Normally, the water happily re-enters the hydrological cycle without any intervention on my part. Except today. When I'm working at home.

So, a good 40 minutes was lost finding the drain snake, snaking the drain, pulling up unspeakable filth and finally clearing the drain.

So, please feel free to choose a moral for this story:

1) Don't work at home!

2) When working at home, don't bother with household tasks.

3) Remind your significant other that hay and shavings from the rabbit's cage shouldn't be washed down the drain in the laundry room.

4) Any combination of (3) and the other options.

I think I'll empty the dishwasher now... :)