Friday February 29, 2008

Happy Leap Day!

Happy Leap Day! Today, February 29th, comes only once every four years. Of course most of you probably know all of this already. Most of you, but probably somewhat fewer, know *why* we have leap years. The short answer is to keep the calendar in synch with the seasons. A longer explanation can be found here.

A deeper question is, why do we need the calendar to be in synch with the seasons? I'm not sure. Some origins are probably religious, so that we wouldn't have Easter in the winter and Christmas in the fall. Other reasons might be agricultural, so that people know when to plant and when to harvest and when the Nile is likely to flood. In today's modern age this is probably no longer necessary. The fixation on seasons probably originated in the northern hemisphere; the folks in Australia don't seem to complain that Christmas is in the summer. Well, maybe they do, but I haven't heard them.

What's notable about leap year is that it's based on actual astronomical principles: the relationship of the day to the year. This is unlike Daylight Saving Time, which is purely a social construction. DST doesn't actually save anything, and it causes a lot of confusion. Occasionally somebody is an hour off the next day, and occasionally I'm startled by the odd clock that I forgot to reset. Worse, different countries change times on different dates, so the usual time zone differences -- bad enough to begin with -- are temporarily made worse.

Leap years I can live with, but let's just get rid of DST.

Friday February 22, 2008

More = Better ?

I had a discussion yesterday that touched briefly upon how agile our project is (or is not). The answer was that we're probably more agile than some other projects I've been on, but that we could be more agile. The underlying assumption was that things would be better if we were more agile. I think this assumption happens to be true, but it's not fundamentally true. Let me explain.

A former manager once said to me that he thought I was process-oriented. My response was, quite emphatically, "I'm not process-oriented; I'm results-oriented!" (I swear this is true. It just popped out.) The reason I'm a proponent of agile techniques is that I think we can achieve better results using them. Otherwise, what would be the point? If we made some change that was more agile, but our results didn't improve, there wouldn't be any benefit. Or if we made some change that did improve our results, I'd be in favor of it regardless of whether or it's considered "agile".

Note also that I'm using "results" in a very generalized way. For instance, if the team were to deliver the same product, feature set, quality, etc. but with less overtime and stress, and more time spent relaxing with families, and so forth, I'd consider that to be an improved result.

The default in my area seems to be for projects to be very plan-driven. Frankly, I don't think they've worked well. For this reason I've looked to alternatives, including many agile techniques. But the point isn't to be agile for the sake of being agile; it's to get better results. Let's make sure we don't forget this.