I just read the two articles by Brian Marick on Emerson, Methodologies and Ontology. Really Interesting Stuff, but it was dense. It deserves a second and third read. Marick points to Kent Beck, who wrote that, essentially, when the code is trying to tell you what to do, try to follow it. According to Marick, developers are in a dance of agency with the software we write, as the software emerges. (You can read it for yourself, it's good stuff:
Now, I used to be a huge Issac Asimov Fan, and I remember one essay where he talked about how his characters essentially 'take over' the story. One moment, he is directing the stoy, the next, the characters are simply doing what they would do next. That's flow for Asimov, getting to the place where story is writing itself, and he's a kind of passenger. I think this is what Marick means by unreflective actions "actions people take because they are the obvious things to do in
I think Emerson was trying to get at the incredible potential of humanity - I know that Asimov was. I don't see any big disparities between the Emersonian worldview and my own faith - for example, we Catholics believe that creativity is an attribute of God's Character, and thus expressing that attribute is an act that is essentially divine. "Joyous" is about as close as you can get in secular terminology.
Which brings me to why I love what I do. I love it so much that don't want to stop, even on a Sunday at 9:30AM over the rockies. If development is a road race, the "Process Improvement" folks found a single road rut and then created a process which must always be followed, regarless of weather or not your particular road had a rut. In the end, driving around those extra gates and cones can take more time than driving through. The agile folks are focusing on removing the cones and gates that don't make sense; they want the simplest commute that could possibly work.
IMHO, The next step will be a methodology that puts a better engine in the car - and that reads more like mentoring and coaching and skills improvement, combined with a light-weight, description ("how we generally think about problems here") framework over a prescriptive ("do it this way or else") methodology.
What's my point? What we're doing here, all this talk about constant improvement and how to do it better - that _is_ the methodology. Expanding our experiences and knowledge. Sharpening the saw. I'm having a blast. Thanks for being along for the ride.