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

Design Maps online

Expand Messages
  • Jim Shore
    About six weeks ago, I asked people to send me their design maps--a little conversational tool for discussing an approach to design. I ran a little bit late,
    Message 1 of 6 , Feb 6, 2006
    • 0 Attachment
      About six weeks ago, I asked people to send me their design maps--a
      little conversational tool for discussing an approach to design.

      I ran a little bit late, but I've finally posted those design maps. You
      can find them here:

      http://www.jamesshore.com/Blog/Your-Design-Maps.html

      Cheers,
      Jim
      --
      James Shore -- Titanium IT -- Successful Software
      Recipient of 2005 Gordon Pask award for
      Contributions to Agile Practice

      phone: 503-267-5490
      email: jshore@...
      web/blog: http://www.jamesshore.com
    • Ron Jeffries
      ... You note that all the maps were different. This makes me wonder whether people really know accurately what their maps are, or are recording them properly.
      Message 2 of 6 , Feb 7, 2006
      • 0 Attachment
        On Monday, February 6, 2006, at 4:52:16 PM, Jim Shore wrote:

        > About six weeks ago, I asked people to send me their design maps--a
        > little conversational tool for discussing an approach to design.

        > I ran a little bit late, but I've finally posted those design maps. You
        > can find them here:

        > http://www.jamesshore.com/Blog/Your-Design-Maps.html

        You note that all the maps were different. This makes me wonder
        whether people really know accurately what their maps are, or are
        recording them properly.

        For example, you, Jim, report zero predictive design for anything
        other than methods. I certainly mean no disrespect, but how sure are
        you that you NEVER think about the classes that might show up in
        some new program? Really never? You don't ever look at a class
        that's getting a bit grubby and think about what it might mean?

        It could be true -- I'm just asking. But /never/? That would
        surprise me.

        Ron Jeffries
        www.XProgramming.com
        This is how I develop software.
        Take the parts that make sense to you.
        Ignore the rest.
      • usidoesit
        ... They all have different thinking targets. It has potential as an interesting heuristic, but everyone would need the same target if you were going to
        Message 3 of 6 , Feb 7, 2006
        • 0 Attachment
          --- In extremeprogramming@yahoogroups.com, Ron Jeffries
          <ronjeffries@...> wrote:
          >
          > > http://www.jamesshore.com/Blog/Your-Design-Maps.html
          >
          > You note that all the maps were different. This makes me wonder
          > whether people really know accurately what their maps are, or are
          > recording them properly.

          They all have different thinking targets. It has potential as an
          interesting heuristic, but everyone would need the same target if you
          were going to compare results.

          > For example, you, Jim, report zero predictive design for anything
          > other than methods. I certainly mean no disrespect, but how sure are
          > you that you NEVER think about the classes that might show up in
          > some new program? Really never? You don't ever look at a class
          > that's getting a bit grubby and think about what it might mean?

          Wouldn't grubby code be "reflections" in the eye of the beholder? ;-)

          Here you've chosen reality as a counter-example, fair enough.

          I would have to put "p,r" in every square, honestly. But that's only
          because my thinking target jumps around to all different kinds of
          examples.

          Maybe think though, now which example could it possibly be true of,
          zero predictive design?

          Without a target, no problem can begin to be defined, and without a
          defined problem the heuristic simply fires silver bullets randomly,
          no wonder there's so much waste in apps dev...

          Best,
          -R

          --

          http://groups.yahoo.com/group/heuristic/

          Pick a target, define the problem... Free books and newsletters.
        • Jim Shore
          Hi, Ron, ... You ... That s a fair question. I think design maps are just the start of the conversation. So far, they ve turned out to be a pretty good
          Message 4 of 6 , Feb 7, 2006
          • 0 Attachment
            Hi, Ron,

            --- In extremeprogramming@yahoogroups.com, Ron Jeffries
            <ronjeffries@...> wrote:
            >
            > On Monday, February 6, 2006, at 4:52:16 PM, Jim Shore wrote:
            >
            > > About six weeks ago, I asked people to send me their design maps--a
            > > little conversational tool for discussing an approach to design.
            >
            > > I ran a little bit late, but I've finally posted those design maps.
            You
            > > can find them here:
            >
            > > http://www.jamesshore.com/Blog/Your-Design-Maps.html
            >
            > You note that all the maps were different. This makes me wonder
            > whether people really know accurately what their maps are, or are
            > recording them properly.

            That's a fair question. I think design maps are just the start of the
            conversation. So far, they've turned out to be a pretty good kickstart
            for productive conversations about design that transcend the BDUF vs. XP
            arguments that seem so common. That's as much as I could hope for.

            > For example, you, Jim, report zero predictive design for anything
            > other than methods. I certainly mean no disrespect, but how sure are
            > you that you NEVER think about the classes that might show up in
            > some new program? Really never? You don't ever look at a class
            > that's getting a bit grubby and think about what it might mean?
            >
            > It could be true -- I'm just asking. But /never/? That would
            > surprise me.

            Good! Let's have a conversation about it. I'd like to see what your
            design map would look like, too.

            But first, I think I need to be more clear about what I mean with
            regards to predictive vs. reflective design. When I reported zero
            predictive design for classes, packages, and products, I didn't mean to
            say that I didn't think about the future at all. I'm constantly
            thinking about possible design directions. I'll go up to the whiteboard
            and discuss ideas with the rest of the team.

            Similarly, if I see a class that's a little bit grubby, I absolutely
            think about how I could refactor it. I look at the whole design and ask
            if there's similar problems occurring elsewhere. I might talk with the
            whole team about how we can improve the design and what the resulting
            design of the system would look like.

            What I /don't/ do is write code to match my design ideas. I wait until
            the code has been written, then refactor it.

            That's not entirely true... when I'm creating new code, of course I have
            to have a place to put it. I don't just add code to an existing method
            and then factor it out. I create new methods and I create new classes.
            But it's more about how the new code fits into the existing design
            than imagining any new design and writing the code around those ideas.
            New design ideas come out through analysis of existing code and refactoring.

            So, by "predictive design," I mean "imagining a new design and then
            writing code that creates the design." I don't do that. I do
            "reflective design:" "examining existing code, extrapolating its design,
            and improving that design with refactoring."

            I'm still trying to understand and clarify these concepts. I see a big
            difference between the way I do design now, since I've learned XP, and
            the way I used to design. "Predictive" and "reflective" is my best
            attempt to describe these differences. Thanks for your critical
            inquiry--it helps me refine these thoughts.

            Cheers,
            Jim


            --
            James Shore -- Titanium IT -- Successful Software
            Recipient of 2005 Gordon Pask award for
            Contributions to Agile Practice

            phone: 503-267-5490
            email: jshore@...
            web/blog: http://www.jamesshore.com
          • Steven Gordon
            Jim, Given your definition that predictive design which is not immediately implemented does not map to predictive design, I will have to submit a refactored
            Message 5 of 6 , Feb 7, 2006
            • 0 Attachment
              Jim,

              Given your definition that predictive design which is not immediately
              implemented does not map to predictive design, I will have to submit a
              refactored map. I suspect it will look much like yours.

              Steven Gordon

              On 2/7/06, Jim Shore <jshore@...> wrote:
              . . .

              But first, I think I need to be more clear about what I mean with
              > regards to predictive vs. reflective design. When I reported zero
              > predictive design for classes, packages, and products, I didn't mean to
              > say that I didn't think about the future at all. I'm constantly
              > thinking about possible design directions. I'll go up to the whiteboard
              > and discuss ideas with the rest of the team.
              >
              > . . .


              Cheers,
              > Jim
              >
              >
              > --
              > James Shore -- Titanium IT -- Successful Software
              > Recipient of 2005 Gordon Pask award for
              > Contributions to Agile Practice
              >
              > phone: 503-267-5490
              > email: jshore@...
              > web/blog: http://www.jamesshore.com
              >


              [Non-text portions of this message have been removed]
            • Ron Jeffries
              ... Yes, I think they d be a great basis for a conversation. Could imagine a wonderful panel at Agile 2006 where people talked about the maps, and their maps.
              Message 6 of 6 , Feb 7, 2006
              • 0 Attachment
                On Tuesday, February 7, 2006, at 6:50:25 PM, Jim Shore wrote:

                >> You note that all the maps were different. This makes me wonder
                >> whether people really know accurately what their maps are, or are
                >> recording them properly.

                > That's a fair question. I think design maps are just the start of the
                > conversation. So far, they've turned out to be a pretty good kickstart
                > for productive conversations about design that transcend the BDUF vs. XP
                > arguments that seem so common. That's as much as I could hope for.

                Yes, I think they'd be a great basis for a conversation. Could
                imagine a wonderful panel at Agile 2006 where people talked about
                the maps, and their maps.

                >> For example, you, Jim, report zero predictive design for anything
                >> other than methods. I certainly mean no disrespect, but how sure are
                >> you that you NEVER think about the classes that might show up in
                >> some new program? Really never? You don't ever look at a class
                >> that's getting a bit grubby and think about what it might mean?
                >>
                >> It could be true -- I'm just asking. But /never/? That would
                >> surprise me.

                > Good! Let's have a conversation about it. I'd like to see what your
                > design map would look like, too.

                Sure ...

                > But first, I think I need to be more clear about what I mean with
                > regards to predictive vs. reflective design. When I reported zero
                > predictive design for classes, packages, and products, I didn't mean to
                > say that I didn't think about the future at all. I'm constantly
                > thinking about possible design directions. I'll go up to the whiteboard
                > and discuss ideas with the rest of the team.

                Yes, me too. I love to do it, and I'm always doing it ...

                > Similarly, if I see a class that's a little bit grubby, I absolutely
                > think about how I could refactor it. I look at the whole design and ask
                > if there's similar problems occurring elsewhere. I might talk with the
                > whole team about how we can improve the design and what the resulting
                > design of the system would look like.

                Yes. When I think about improving a program, I often think at a
                level of modularity that is higher, more general, less specific than
                the code.

                "We need to divide this responsibility up somehow. Maybe there
                could be one bunch of objects that manage the storage and another
                bunch that manipulate the bytes, without regard to how things are
                stored."

                I would guess that /Adventures/ has zillions of examples of that
                kind of speculation (prediction?), and similarly for the current XST
                series on my site.

                Sounds like we do similar things so far ...

                > What I /don't/ do is write code to match my design ideas. I wait until
                > the code has been written, then refactor it.

                Yes. I try NEVER to create an object just because I think I'll need
                it. Sometimes I mess up ... and sometimes I create an object just
                because I want to see what it would look like. That's somewhat
                predictive, somewhat reflective, somewhat experimental ...

                > That's not entirely true... when I'm creating new code, of course I have
                > to have a place to put it. I don't just add code to an existing method
                > and then factor it out. I create new methods and I create new classes.

                Yes. But if one has written the test first, a case can be made that
                even that is [mostly?] reflective.

                > But it's more about how the new code fits into the existing design
                > than imagining any new design and writing the code around those ideas.
                > New design ideas come out through analysis of existing code and refactoring.

                Yes ... your words so far have me nodding in agreement. The way I
                understand the word "predictive" -- maybe I mean "speculative" --
                there's a lot of thinking about what might be. With you, I don't
                express much of the "might be" in the real code.

                > So, by "predictive design," I mean "imagining a new design and then
                > writing code that creates the design." I don't do that. I do
                > "reflective design:" "examining existing code, extrapolating its design,
                > and improving that design with refactoring."

                OK ... for me, though, there's a bit more. I feel, sometimes, that
                TDD is causing the design just to "emerge". I know, however, that
                it's really my judgment that is causing the design to emerge. And
                that judgment is strongly informed, and somewhat influenced, by my
                thoughts about what the design wants to be.

                I try not to follow my early imaginings of what the program might
                be. In fact, it is fun when doing a TDD demo to imagine a design
                with the group -- and then have the resulting program turn out
                completely differently, with each step making perfectly good sense.

                In the end, though, even with something as simple as my favorite
                example of scoring a bowling game, I suspect that by the time the
                program was big enough to run a scoring machine, the objects and
                relationships would turn out to look a lot like the design we might
                initially imagine.

                I'm not convinced that's just chance, nor that TDD just "discovers"
                that same design. I suspect there's an aspect of guidance involved.

                At the same time, I wouldn't be surprised to see some major
                variances with what we imagined ... sometimes because what we
                imagined was a bad idea, sometimes because a different similarly
                good idea caught our eye, and maybe even sometimes because we
                reflected our way to an inferior idea where the "up front" design
                might have been more right.

                > I'm still trying to understand and clarify these concepts. I see a big
                > difference between the way I do design now, since I've learned XP, and
                > the way I used to design. "Predictive" and "reflective" is my best
                > attempt to describe these differences. Thanks for your critical
                > inquiry--it helps me refine these thoughts.

                I fully agree with the difference and I feel strongly that all of us
                who have gone down the TDD path laid out by Kent have had much the
                same experience. Whether the words p and r are just right isn't as
                important, as you suggest, as the conversations that are started,
                and as the starting ideas that may help other people to similar
                discoveries as we've made.

                Thanks for doing it!

                Ron Jeffries
                www.XProgramming.com
                Show me the features!
              Your message has been successfully submitted and would be delivered to recipients shortly.