Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

heusserm (4461)

heusserm
  (email not shown publicly)
http://www.xndev.com/
AOL IM: MatthewHeusser (Add Buddy, Send Message)

Matt Heusser is JAPH and an XP-Er [xprogramming.com]. (The Methodology, not the Operating System.) Right now, he's doing a lot of Test Driven Development in Perl.

Journal of heusserm (4461)

Tuesday September 20, 2005
12:39 AM

Emerson

[ #26795 ]
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.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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
    Struc