Emerson

heusserm on 2005-09-20T05:39:14

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: this and this)

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.


reflective comment

mr_bean on 2005-09-20T09:24:18

This part:

      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.
                g a blast. Thanks for being along for the ride.
made me think of a quote from John Barth in
Structure and Interpretation of Computer Programs:

Metalinguistic Abstraction
************************** ... It's in words that the magic is--Abracadabra, Open Sesame, and
          the rest--but the magic words in one story aren't magical in the
          next. The real magic is to understand which words work, and when,
          and for what; the trick is to learn the trick. ... And those words are made from the letters of our alphabet: a
          couple-dozen squiggles we can draw with the pen. This is the key!
          And the treasure, too, if we can only get our hands on it! It's
          as if--as if the key to the treasure _is_ the treasure!

          --John Barth, `Chimera'

Reading the journal and the Brian Marick essays makes me want to
get on some XP, or Agile maillists.

Marick mentions the testdrivendevelopment and agile-testing
Yahoogroups list(s).