Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Blog entry: The Other Side of Design

Expand Messages
  • Jay Flowers
    Jim, In your blogging of this, when you call it Continuous Design, I got the feeling that it was about getting experience to help guide refactoring. The key
    Message 1 of 106 , Oct 27, 2005
      Jim,
      In your blogging of this, when you call it Continuous Design, I got
      the feeling that it was about getting experience to help guide
      refactoring. The key being that having experience to steer you
      enables you to make better decisions. All this is going on in the
      context of peer programming, or Continuous Review. So in many
      microcycles before checking into the build you have designed, written
      tests, written code, tested, and reviewed. As well you made it sound
      as if thinking about design before entering into a cycle was a bad
      thing. I don't remember any mention of reflection on the design after
      the cycle was complete.
      Now I get the feeling that you are talking about something completely
      different. Thinking about design before and after the cycle,
      predictive and reflective. Did I miss the boat?

      On 10/26/05, Steven J. Owens <xp@...> wrote:
      > On Mon, Oct 24, 2005 at 01:05:46PM -0400, Jim Shore wrote:
      > > I didn't mean predictive / reflective as picture / code.
      > >
      > > predictive: designing for code that is yet to be written
      > > reflective: designing based on code that has already been written
      >
      > I'm tending to think of Jim's take on it as "designing outside my
      > head", as in, it's easier/better to put the design down in black and
      > white in some logical representaiton - like source code - and then
      > manipulate that logical representation to improve the design, than to
      > try to envision it all pure and complete in my head.
      >
      > My first thought on reading the phrase was of a subtly different
      > sense, though I guess I'd have a hard time imagining one without the
      > other. That's the sense of the distinction between getting it out of
      > my head - a very brainstorm-ish state of mind - and actually designing
      > it. The process of attempting to articulate what I want to say (in
      > code) interferes with the process - and possibly interferes with
      > attaining the most effective state of mind - of trying to figure out
      > how to say it most effectively.
      >
      > --
      > Steven J. Owens
      > puff@...
      >
      > "I'm going to make broad, sweeping generalizations and strong,
      > declarative statements, because otherwise I'll be here all night and
      > this document will be four times longer and much less fun to read.
      > Take it all with a grain of salt." - http://darksleep.com/notablog
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >


      --
      Jay Flowers
      ----------------------------------------------------------------------
      http://jayflowers.com
      ---------------------------------------------------------------------
    • Jay Flowers
      Jim, In your blogging of this, when you call it Continuous Design, I got the feeling that it was about getting experience to help guide refactoring. The key
      Message 106 of 106 , Oct 27, 2005
        Jim,
        In your blogging of this, when you call it Continuous Design, I got
        the feeling that it was about getting experience to help guide
        refactoring. The key being that having experience to steer you
        enables you to make better decisions. All this is going on in the
        context of peer programming, or Continuous Review. So in many
        microcycles before checking into the build you have designed, written
        tests, written code, tested, and reviewed. As well you made it sound
        as if thinking about design before entering into a cycle was a bad
        thing. I don't remember any mention of reflection on the design after
        the cycle was complete.
        Now I get the feeling that you are talking about something completely
        different. Thinking about design before and after the cycle,
        predictive and reflective. Did I miss the boat?

        On 10/26/05, Steven J. Owens <xp@...> wrote:
        > On Mon, Oct 24, 2005 at 01:05:46PM -0400, Jim Shore wrote:
        > > I didn't mean predictive / reflective as picture / code.
        > >
        > > predictive: designing for code that is yet to be written
        > > reflective: designing based on code that has already been written
        >
        > I'm tending to think of Jim's take on it as "designing outside my
        > head", as in, it's easier/better to put the design down in black and
        > white in some logical representaiton - like source code - and then
        > manipulate that logical representation to improve the design, than to
        > try to envision it all pure and complete in my head.
        >
        > My first thought on reading the phrase was of a subtly different
        > sense, though I guess I'd have a hard time imagining one without the
        > other. That's the sense of the distinction between getting it out of
        > my head - a very brainstorm-ish state of mind - and actually designing
        > it. The process of attempting to articulate what I want to say (in
        > code) interferes with the process - and possibly interferes with
        > attaining the most effective state of mind - of trying to figure out
        > how to say it most effectively.
        >
        > --
        > Steven J. Owens
        > puff@...
        >
        > "I'm going to make broad, sweeping generalizations and strong,
        > declarative statements, because otherwise I'll be here all night and
        > this document will be four times longer and much less fun to read.
        > Take it all with a grain of salt." - http://darksleep.com/notablog
        >
        >
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
        >
        > ad-free courtesy of objectmentor.com
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >


        --
        Jay Flowers
        ----------------------------------------------------------------------
        http://jayflowers.com
        ---------------------------------------------------------------------
      Your message has been successfully submitted and would be delivered to recipients shortly.