Øredev and the Renaissance?

I am on my way home from Øredev 2008 where I presented on OSGi which seemed to have been well received by my kind audience.

This was an interesting conference for me (aside from the blizzard I walked into as I left the conference on Friday evening). Most of the conferences I attend are all Java (JavaOne, EclipseCon). This one had Java but also .Net and other things relevant to programmers. One area that got a bunch of focus was programming methodologies like Agile, Scrum, etc. I will confess to be not very familiar with their details but I think it is great that these things are discussed at conferences.

During the final session of the conference, a panel discussion which featured some of the bigger names of the conference, a lot of the discussion centered on these programming methodologies. The discussion included things like how they should be applied, whether one methodology was better than another or even whether one should rigorously follow a methodology or just pick the parts you like. The term Renaissance was used quite often (in fact it appeared in the titles of the daily keynotes) as if there was some renaissance in progress in the programming community. Perhaps people using these programming methodologies means a renaissance?

But what really started to bother me as I thought about it during this panel discussion, was that no one seemed to discuss any science behind these methods which prove their effectiveness and utility. Is there any scientific studies which demonstrate these methods really help? or hurt? That some are better than others? Perhaps we don't need so much of a renaissance as we need an enlightenment and apply some rational science to evaluating these different ideas instead of being dogmatic about them. If we programmers want to be professional, we need operate based upon science (like astronomers) and not pseudoscience (like astrologers).

One of the panelists quoted Bill and Ted and simply suggested we programmers Be Excellent! That is great advice for all things in life but not specifically helpful for programmers.