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

Re: [XP] Defining stories in an embedded system

Expand Messages
  • Ron Jeffries
    ... Why do you believe that the drivers have to exist before user stories can be defined? What will the users and customers do with the system when it is
    Message 1 of 18 , Nov 1, 2001
    • 0 Attachment
      Around Thursday, November 01, 2001, 11:24:08 AM, malekb@... wrote:

      > How do you go about defining stories/iterations when you're dealing
      > with an embedded system that requires a large part (approx 70%) of
      > the system to exist (i.e. drivers & middleware) before customer and
      > end user stories can be defined?
      > Any thoughts???
      > Let me know.

      Why do you believe that the drivers have to exist before user stories
      can be defined?

      What will the users and customers do with the system when it is
      finally delivered?

      Ron Jeffries
      www.XProgramming.com
      The practices are not the knowing: they are a path to the knowing.
    • Bryan Dollery
      Baher wrote ... You don t have to build the whole of your drivers, or the whole of your middleware up front. You can, and possibly should, allow these things
      Message 2 of 18 , Nov 1, 2001
      • 0 Attachment
        Baher wrote
        > How do you go about defining stories/iterations when you're dealing
        > with an embedded system that requires a large part (approx 70%) of
        > the system to exist (i.e. drivers & middleware) before customer and
        > end user stories can be defined?
        > Any thoughts???
        > Let me know.

        You don't have to build the whole of your drivers, or the whole of your
        middleware up front. You can, and possibly should, allow these things to
        evolve too. If your driver can provide say 20 functions, then you probably
        won't need them all to support the first story, so just develop the ones
        your need at first. The same applies to your middleware; you need to send
        mesages?, try creating only those messages that are necessary to the current
        story. If you mean the creation of low-level middleware, then again you can
        evolve this. Create only those protocol elements that you need to support
        the current story.

        If your story really requires 70% of the functionality then break the story
        down. Does it say "process file" (for eample)? Then change it to "identify
        file", "locate file", "open file for io", "backup file", "read file", "parse
        file", "process records", "render results", "write file", "close file", etc.

        Bryan
      • kevinxp@qualitycode.com
        ... Also: Does your team control development of either the drivers or middleware? Or are they third-party products? How much development can you do on some
        Message 3 of 18 , Nov 1, 2001
        • 0 Attachment
          --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
          > Around Thursday, November 01, 2001, 11:24:08 AM, malekb@t... wrote:
          >
          > > How do you go about defining stories/iterations when you're dealing
          > > with an embedded system that requires a large part (approx 70%) of
          > > the system to exist (i.e. drivers & middleware) before customer and
          > > end user stories can be defined?
          > > Any thoughts???
          > > Let me know.
          >
          > Why do you believe that the drivers have to exist before user stories
          > can be defined?
          >
          > What will the users and customers do with the system when it is
          > finally delivered?

          Also:

          Does your team control development of either the drivers or
          middleware? Or are they third-party products?

          How much development can you do on some kind of emulator, and how
          much needs to be done on an actual target?

          Kevin
        • malekb@tce.com
          ... dealing ... of ... and ... stories ... I guess it s not that the drivers would have to exist before stories could be defined, but that any story that you d
          Message 4 of 18 , Nov 1, 2001
          • 0 Attachment
            --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
            > Around Thursday, November 01, 2001, 11:24:08 AM, malekb@t... wrote:
            >
            > > How do you go about defining stories/iterations when you're
            dealing
            > > with an embedded system that requires a large part (approx 70%)
            of
            > > the system to exist (i.e. drivers & middleware) before customer
            and
            > > end user stories can be defined?
            > > Any thoughts???
            > > Let me know.
            >
            > Why do you believe that the drivers have to exist before user
            stories
            > can be defined?

            I guess it's not that the drivers would have to exist before stories
            could be defined, but that any story that you'd come up with would
            inevitably depend on them.

            >
            > What will the users and customers do with the system when it is
            > finally delivered?

            This would be a set-top box type of application.

            >
            > Ron Jeffries
            > www.XProgramming.com
            > The practices are not the knowing: they are a path to the knowing.
          • malekb@tce.com
            ... dealing ... of ... and ... stories ... Usually it s a mix. We develop at the driver, middleware and application levels and team with 3rd parties based on
            Message 5 of 18 , Nov 1, 2001
            • 0 Attachment
              --- In extremeprogramming@y..., kevinxp@q... wrote:
              > --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...>
              wrote:
              > > Around Thursday, November 01, 2001, 11:24:08 AM, malekb@t...
              wrote:
              > >
              > > > How do you go about defining stories/iterations when you're
              dealing
              > > > with an embedded system that requires a large part (approx 70%)
              of
              > > > the system to exist (i.e. drivers & middleware) before customer
              and
              > > > end user stories can be defined?
              > > > Any thoughts???
              > > > Let me know.
              > >
              > > Why do you believe that the drivers have to exist before user
              stories
              > > can be defined?
              > >
              > > What will the users and customers do with the system when it is
              > > finally delivered?
              >
              > Also:
              >
              > Does your team control development of either the drivers or
              > middleware? Or are they third-party products?

              Usually it's a mix. We develop at the driver, middleware and
              application levels and team with 3rd parties based on
              business/contract arrangements.

              >
              > How much development can you do on some kind of emulator, and how
              > much needs to be done on an actual target?

              We typically do most of our development on the actual target in
              conjunction with other test equipment. Most of our teams don't have
              the time develop emulators that bear a close enough resemblance to
              the real thing.

              >
              > Kevin
            • Dinwiddie, George
              Hi, Baher, While I wasn t working using XP or even test-first at the time, I ve done some set-top box development at Welcome To The Future, a now-defunct
              Message 6 of 18 , Nov 1, 2001
              • 0 Attachment
                Hi, Baher,

                While I wasn't working using XP or even test-first at the time,
                I've done some set-top box development at Welcome To The Future,
                a now-defunct company. If you're doing development on the target
                system, you must have a decent OS (at WTTF we used QNX) and some
                i/o for entering and compiling code. Therefore you can create
                stubs for your drivers that take input from the keyboard and
                display output on the screen. Actually, you can do this in a
                cross-compilation environment, too. If you write your test first,
                creating these mock drivers as you need them, I think you'll be
                amazed at how far you can go without the need for real drivers.
                Not only that, you'll go there faster because you can check much
                of your code with the higher bandwith user interface that your
                terminal provides. Try it, and I think you'll be pleasantly
                surprised.

                - George

                > -----Original Message-----
                > From: malekb@... [mailto:malekb@...]
                > Sent: Thursday, November 01, 2001 1:13 PM
                > To: extremeprogramming@yahoogroups.com
                > Subject: Re: [XP] Defining stories in an embedded system
                >
                >
                > --- In extremeprogramming@y..., kevinxp@q... wrote:
                > > --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...>
                > wrote:
                > > > Around Thursday, November 01, 2001, 11:24:08 AM, malekb@t...
                > wrote:
                > > >
                > > > > How do you go about defining stories/iterations when you're
                > dealing
                > > > > with an embedded system that requires a large part (approx 70%)
                > of
                > > > > the system to exist (i.e. drivers & middleware) before customer
                > and
                > > > > end user stories can be defined?
                > > > > Any thoughts???
                > > > > Let me know.
                > > >
                > > > Why do you believe that the drivers have to exist before user
                > stories
                > > > can be defined?
                > > >
                > > > What will the users and customers do with the system when it is
                > > > finally delivered?
                > >
                > > Also:
                > >
                > > Does your team control development of either the drivers or
                > > middleware? Or are they third-party products?
                >
                > Usually it's a mix. We develop at the driver, middleware and
                > application levels and team with 3rd parties based on
                > business/contract arrangements.
                >
                > >
                > > How much development can you do on some kind of emulator, and how
                > > much needs to be done on an actual target?
                >
                > We typically do most of our development on the actual target in
                > conjunction with other test equipment. Most of our teams don't have
                > the time develop emulators that bear a close enough resemblance to
                > the real thing.
                >
                > >
                > > Kevin
                >
                >
                > To Post a message, send it to: extremeprogramming@...
                >
                > To Unsubscribe, send a blank message to:
                > extremeprogramming-unsubscribe@...
                >
                > ad-free courtesy of objectmentor.com
                >
                > Your use of Yahoo! Groups is subject to
                > http://docs.yahoo.com/info/terms/
                >
                >
              • malekb@tce.com
                ... your ... things to ... probably ... ones ... A low-level driver seems like more of an all-or-nothing type of area. If I need to interface to a console via
                Message 7 of 18 , Nov 1, 2001
                • 0 Attachment
                  > You don't have to build the whole of your drivers, or the whole of
                  your
                  > middleware up front. You can, and possibly should, allow these
                  things to
                  > evolve too. If your driver can provide say 20 functions, then you
                  probably
                  > won't need them all to support the first story, so just develop the
                  ones
                  > your need at first.

                  A low-level driver seems like more of an all-or-nothing type of
                  area. If I need to interface to a console via RS232, I need an RS232
                  driver that allows me to do that. Now maybe you mean additional
                  options/features over and above the bare bones connectivity. I would
                  agree that those things could come later, but the basic functionality
                  of the driver (tx, rx, interrupts, etc) has to be there to minimal
                  service to its clients.
                • kevinxp@qualitycode.com
                  ... It helps to have a concrete example like this. Yes, I would agree that a _simple_ console RS232 driver would be a single unit of work. Now, I ve seen a lot
                  Message 8 of 18 , Nov 1, 2001
                  • 0 Attachment
                    --- In extremeprogramming@y..., malekb@t... wrote:
                    > A low-level driver seems like more of an all-or-nothing type of
                    > area. If I need to interface to a console via RS232, I need an RS232
                    > driver that allows me to do that. Now maybe you mean additional
                    > options/features over and above the bare bones connectivity. I would
                    > agree that those things could come later, but the basic functionality
                    > of the driver (tx, rx, interrupts, etc) has to be there to minimal
                    > service to its clients.

                    It helps to have a concrete example like this. Yes, I would agree that a
                    _simple_ console RS232 driver would be a single unit of work. Now, I've seen a
                    lot of console drivers that have gone way beyond simple.

                    However, this is actually a tool for developers, and not something that a
                    customer would ever want or need. It's more like setting up version control.

                    For the app itself, I'm picturing something like my digital cable box. It probably
                    has 50 features--program info, grid browsing, messages from AT&T, search by
                    category, local weather, etc.

                    In XP terms, each one of those would be one (or more) stories. I would think
                    my first story would be something like:

                    "Be able to install the box between input and output devices, and have channel
                    2 appear on the output." Perhaps even that's too big--I don't know how simple
                    or complex these things are to code. Probably next would be "provide correct
                    sound output"

                    Some other possible stories, which would be prioritized by the customer:
                    "mute toggle (no visual indication)"
                    "channel up (and down) (no visual)"
                    "volume up (and down) (no visual)"
                    "visually indicate mute mode"
                    "visually indicate channel change"
                    "OK button to display current channel"
                    "Add current program summary to OK display"
                    "Add advertisement to OK display"

                    I think you get the idea. Stories are about user-level functionality.

                    Now, do you need drivers to display channel 2 without sound? If so, there
                    might be a way to break that story down. If not, then each of these stories
                    seems really incremental to me.

                    And I ***completely*** agree that if you use Mock objects extensively, you
                    should be able to develop a great deal without relying on your target. That
                    does, of course, assume that you can at least execute a "hello world" in some
                    kind of non-target environment. Perhaps ANSI C?

                    We would love to hear more about your situation, if you're willing to share.

                    Kevin
                  • Dossy
                    ... ... and this is a bad thing, why? Would the Stories not serve a useful purpose to guide those who are responsible for implementing the drivers to focus on
                    Message 9 of 18 , Nov 1, 2001
                    • 0 Attachment
                      On 2001.11.01, malekb@... <malekb@...> wrote:
                      > > Why do you believe that the drivers have to exist before user
                      > > stories can be defined?
                      >
                      > I guess it's not that the drivers would have to exist before stories
                      > could be defined, but that any story that you'd come up with would
                      > inevitably depend on them.

                      ... and this is a bad thing, why?

                      Would the Stories not serve a useful purpose to guide those who
                      are responsible for implementing the drivers to focus on delivering
                      the parts of the drivers that correspond directly to the highest
                      priority business needs (the highest priority stories)?

                      I would rather have the driver implementation team implementing
                      the parts of the driver that I need first, first. Rather than
                      implementing off in the corner on stuff that I don't really
                      need or care about.

                      Think of Stories as a way of a way of expressing business
                      requirements. Shouldn't this be done before _any_ work is
                      done, at least to some (high level) degree?

                      -- Dossy

                      --
                      Dossy Shiobara mail: dossy@...
                      Panoptic Computer Network web: http://www.panoptic.com/
                      "He realized the fastest way to change is to laugh at your own
                      folly -- then you can let go and quickly move on." (p. 70)
                    • Ron Jeffries
                      ... On the contrary. The console will surely have some language that is _transmitted_ via RS232. Probably it understands characters, escape sequences, etc.
                      Message 10 of 18 , Nov 1, 2001
                      • 0 Attachment
                        Around Thursday, November 01, 2001, 5:57:22 PM, malekb@... wrote:

                        > A low-level driver seems like more of an all-or-nothing type of
                        > area. If I need to interface to a console via RS232, I need an RS232
                        > driver that allows me to do that. Now maybe you mean additional
                        > options/features over and above the bare bones connectivity. I would
                        > agree that those things could come later, but the basic functionality
                        > of the driver (tx, rx, interrupts, etc) has to be there to minimal
                        > service to its clients.

                        On the contrary. The console will surely have some "language" that is
                        _transmitted_ via RS232. Probably it understands characters, escape
                        sequences, etc. The RS232 is just a low-level way to move bits between
                        console and program. Essentially the entire conversation between the
                        program and its console can be -- and in my opinion should be --
                        programmed at an abstract level that assumes the existence of some
                        kind of transmission protocol. When you've got a real console, you
                        hook up the drivers. Until then you can work with and test a mock
                        console whose input and output look like the output and input of the
                        program.

                        It's like this:
                        Console <---language---> program
                        which is implemented as
                        Console <---language--RS232--language---> program
                        that is, the RS232 just transmits "language" from place to place.

                        Does that make sense?

                        Ron Jeffries
                        www.XProgramming.com
                        Life tough is. Then die you do. --Yoda (personal communication)
                      • malekb@tce.com
                        ... RS232 ... would ... functionality ... minimal ... is ... between ... Basically it sounds like your talking about stubbing/simulating software and/or
                        Message 11 of 18 , Nov 2, 2001
                        • 0 Attachment
                          --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
                          > Around Thursday, November 01, 2001, 5:57:22 PM, malekb@t... wrote:
                          >
                          > > A low-level driver seems like more of an all-or-nothing type of
                          > > area. If I need to interface to a console via RS232, I need an
                          RS232
                          > > driver that allows me to do that. Now maybe you mean additional
                          > > options/features over and above the bare bones connectivity. I
                          would
                          > > agree that those things could come later, but the basic
                          functionality
                          > > of the driver (tx, rx, interrupts, etc) has to be there to
                          minimal
                          > > service to its clients.
                          >
                          > On the contrary. The console will surely have some "language" that
                          is
                          > _transmitted_ via RS232. Probably it understands characters, escape
                          > sequences, etc. The RS232 is just a low-level way to move bits
                          between
                          > console and program. Essentially the entire conversation between the
                          > program and its console can be -- and in my opinion should be --
                          > programmed at an abstract level that assumes the existence of some
                          > kind of transmission protocol. When you've got a real console, you
                          > hook up the drivers. Until then you can work with and test a mock
                          > console whose input and output look like the output and input of the
                          > program.
                          >
                          > It's like this:
                          > Console <---language---> program
                          > which is implemented as
                          > Console <---language--RS232--language---> program
                          > that is, the RS232 just transmits "language" from place to place.
                          >
                          > Does that make sense?

                          Basically it sounds like your talking about stubbing/simulating
                          software and/or hardware components when they may not be available
                          (or maybe even when they are available). The only problem is that it
                          seems like a tough sell since it may be percieved as being disposable
                          (and therefore a waste) once the real thing becomes available (or if
                          it already is).
                          Our tendency is to build the system in layers from the ground up
                          (i.e. drivers, middleware, app/gui) instead of in vertical slices
                          (i.e. user-level stories). This is so that low level dependencies
                          are developed first, mid level second, etc. That seems to be our
                          mode of operations.
                          The problem is that this does not lend itself to defining end-to-end
                          stories...

                          >
                          > Ron Jeffries
                          > www.XProgramming.com
                          > Life tough is. Then die you do. --Yoda (personal communication)
                        • malekb@tce.com
                          ... RS232 ... would ... functionality ... minimal ... that a ... I ve seen a ... that a ... control. ... True, but I was only citing this as an example. It
                          Message 12 of 18 , Nov 2, 2001
                          • 0 Attachment
                            --- In extremeprogramming@y..., kevinxp@q... wrote:
                            > --- In extremeprogramming@y..., malekb@t... wrote:
                            > > A low-level driver seems like more of an all-or-nothing type of
                            > > area. If I need to interface to a console via RS232, I need an
                            RS232
                            > > driver that allows me to do that. Now maybe you mean additional
                            > > options/features over and above the bare bones connectivity. I
                            would
                            > > agree that those things could come later, but the basic
                            functionality
                            > > of the driver (tx, rx, interrupts, etc) has to be there to
                            minimal
                            > > service to its clients.
                            >
                            > It helps to have a concrete example like this. Yes, I would agree
                            that a
                            > _simple_ console RS232 driver would be a single unit of work. Now,
                            I've seen a
                            > lot of console drivers that have gone way beyond simple.
                            >
                            > However, this is actually a tool for developers, and not something
                            that a
                            > customer would ever want or need. It's more like setting up version
                            control.
                            >

                            True, but I was only citing this as an example. It may have been the
                            video driver, audio, signal or whatever.


                            > For the app itself, I'm picturing something like my digital cable
                            box.

                            Good example...

                            > It probably has 50 features--program info, grid browsing, messages
                            from AT&T, search by category, local weather, etc.
                            >
                            > In XP terms, each one of those would be one (or more) stories. I
                            would think
                            > my first story would be something like:
                            >
                            > "Be able to install the box between input and output devices, and
                            have channel
                            > 2 appear on the output." Perhaps even that's too big--I don't know
                            how simple
                            > or complex these things are to code. Probably next would
                            be "provide correct
                            > sound output"
                            >
                            > Some other possible stories, which would be prioritized by the
                            customer:
                            > "mute toggle (no visual indication)"
                            > "channel up (and down) (no visual)"
                            > "volume up (and down) (no visual)"
                            > "visually indicate mute mode"
                            > "visually indicate channel change"
                            > "OK button to display current channel"
                            > "Add current program summary to OK display"
                            > "Add advertisement to OK display"
                            >
                            > I think you get the idea. Stories are about user-level
                            functionality.

                            But what if all of this user level functionality is dependent on the
                            same layer middleware layer such that it's no harder to do any one of
                            these than the other?

                            >
                            > Now, do you need drivers to display channel 2 without sound? If so,
                            there
                            > might be a way to break that story down. If not, then each of these
                            stories
                            > seems really incremental to me.

                            What exactly do you mean by this?

                            >
                            > And I ***completely*** agree that if you use Mock objects
                            extensively, you
                            > should be able to develop a great deal without relying on your
                            target.

                            I don't know much about mock objects. It sounds like a
                            stub/simulation method. How is it any different than just writing a
                            stub? My only concern is that there could be some resistance to
                            doing something that is percieved as disposable later. That's what
                            has led to our layered development approach. We develop from the
                            ground up so that the lower layers will be in place for the upper
                            layers. This doesn't seem to lend itself to defining end-to-end user
                            level stories, and that's what I'm trying to figure out...


                            > That does, of course, assume that you can at least execute a "hello
                            world" in some
                            > kind of non-target environment. Perhaps ANSI C?
                            >
                            > We would love to hear more about your situation, if you're willing
                            to share.
                            >
                            > Kevin
                          • kevinxp@qualitycode.com
                            ... Wow. That would be some middleware layer. You re really saying that if all I wanted was a channel 2 video and sound pass-through, that the middleware would
                            Message 13 of 18 , Nov 2, 2001
                            • 0 Attachment
                              --- In extremeprogramming@y..., malekb@t... wrote:
                              > But what if all of this user level functionality is dependent on the
                              > same layer middleware layer such that it's no harder to do any one of
                              > these than the other?

                              Wow. That would be some middleware layer. You're really saying that if all I
                              wanted was a channel 2 video and sound pass-through, that the middleware
                              would be identical to a complete set top box? Really? No input device. No
                              visual overlays above the image, so no font generator...

                              > > Now, do you need drivers to display channel 2 without sound? If so,
                              > > there might be a way to break that story down. If not, then each of
                              > > these stories seems really incremental to me.
                              >
                              > What exactly do you mean by this?

                              Which part?

                              Can you break down the story of displaying channel 2 without sound? Hmmm.
                              Well, I've already implied that this story probably requires less middleware
                              (and fewer drivers) than you have suggested. If I'm wrong, please speak up.

                              Could we break it down further? Sure, how about an output-only device:
                              Display a blank blue screen on the TV. How much infrastructure would that
                              take? How about lighting an LED (but not passing the signal through) when
                              there is a valid input signal? Or, forget the input/output and just support the
                              power on/off button on the front of the box.

                              Or were you asking about the incremental part? I'm trying to break up the
                              functionality such that each story adds just a small amount of total code to
                              the system. The code might all be in one "layer" (see below), or it might be
                              a bit of code at the top, a bit in the middle, and a bit at the bottom.

                              Hopefully, none of the stories require some HUGE infrastructure lump to be
                              developed all at once. In your sample, I would think that the main features
                              that *might* fall into this would be:
                              - passing video through
                              - passing sound through
                              - generating a non-text visual overlay
                              - generating text on screen
                              - accepting input from the front of the box
                              - accepting remote input
                              - accepting meta-information through the signal
                              - connecting to home base through a phone jack
                              - accepting meta-information through the phone jack

                              But, by breaking them up into those very fine slices, hopefully the work of the
                              drivers and middleware layers could be spread out among multiple stories. This
                              has (at least) two big benefits:

                              1. You only code the middleware that you need, so the customer can choose
                              to omit some story and doesn't have to pay for stuff that isn't used.

                              2. You can evolve your design over time, learning as you go, rather than
                              guessing up front what you think the drivers and middleware should look like.

                              > I don't know much about mock objects. It sounds like a
                              > stub/simulation method. How is it any different than just writing a
                              > stub?

                              It's a stub with a specific purpose: Allow you to test and implement the higher
                              levels of the system. Usually they're used because a certain section of code
                              has a trait that makes it hard to test against the real thing, such as:
                              1. Unpredictable (e.g. random number generator, network with traffic)
                              2. Slow (e.g. database, printer, email)
                              3. Hard/slow to set up for the test (e.g. database)
                              4. Limited availability (e.g. rare (or non-existent) hardware)

                              > My only concern is that there could be some resistance to
                              > doing something that is percieved as disposable later.

                              Once you have a mock, you rarely dispose of it. It continues to serve an
                              important role as a test object throughout the life of the project. Near the
                              end, when you're fixing a bug in the upper layer, it's much faster to test
                              and validate your fix against a mock than against the actual target.

                              > That's what has led to our layered development approach. We develop
                              > from the ground up so that the lower layers will be in place for the upper
                              > layers. This doesn't seem to lend itself to defining end-to-end user
                              > level stories, and that's what I'm trying to figure out...

                              True. But someone mentioned, wouldn't the development of the drivers go
                              faster and smoother if the code they served was being written at the same
                              time?

                              You're describing a traditional "horizontal" layered approach to building
                              software. XP works better with "vertical" slices through your system. It's
                              not always easy, but it's almost always possible. Of course, your domain
                              may be an exception...but I wouldn't bet on that.

                              Eagerly awaiting your next posting...

                              Kevin
                            • Dinwiddie, George
                              ... The purpose of using stubs or mock objects is to isolate pieces so they may be thoroughly tested. Any time spent creating stubs to develop and test pieces
                              Message 14 of 18 , Nov 2, 2001
                              • 0 Attachment
                                malekb@... said:
                                >
                                > --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
                                > > Around Thursday, November 01, 2001, 5:57:22 PM, malekb@t... wrote:
                                > >
                                > > Essentially the entire conversation between the
                                > > program and its console can be -- and in my opinion should be --
                                > > programmed at an abstract level that assumes the existence of some
                                > > kind of transmission protocol. When you've got a real console, you
                                > > hook up the drivers. Until then you can work with and test a mock
                                > > console whose input and output look like the output and input of the
                                > > program.
                                > >
                                > > It's like this:
                                > > Console <---language---> program
                                > > which is implemented as
                                > > Console <---language--RS232--language---> program
                                > > that is, the RS232 just transmits "language" from place to place.
                                > >
                                > > Does that make sense?
                                >
                                > Basically it sounds like your talking about stubbing/simulating
                                > software and/or hardware components when they may not be available
                                > (or maybe even when they are available). The only problem is that it
                                > seems like a tough sell since it may be percieved as being disposable
                                > (and therefore a waste) once the real thing becomes available (or if
                                > it already is).
                                > Our tendency is to build the system in layers from the ground up
                                > (i.e. drivers, middleware, app/gui) instead of in vertical slices
                                > (i.e. user-level stories). This is so that low level dependencies
                                > are developed first, mid level second, etc. That seems to be our
                                > mode of operations.
                                > The problem is that this does not lend itself to defining end-to-end
                                > stories...

                                The purpose of using stubs or mock objects is to isolate pieces so
                                they may be thoroughly tested. Any time spent creating stubs to
                                develop and test pieces in isolation without the target hardware will
                                pay itself back quickly and continue to provide paybacks. These are
                                basic tools of the trade. You get the job done faster and better by
                                using sharp tools.

                                If you're not willing to change the way you approach development
                                then you're right, nothing is going to make it any better. You
                                have to have the courage to believe that changing your approach
                                will bring benefits.

                                Years ago, I was writing modem control firmware in an environment
                                that was extremely tool poor. We had no emulator. We had one
                                Intel Microprocessor Development System shared between several
                                engineers. And we had a Tektronix logic analyzer that we could
                                use to capture the address fetches from the ROM to see what path
                                the program took.

                                The accepted development procedure when I started there was to
                                edit your source, assemble it and burn it into an eprom. Then
                                you'd plug the eprom into the hardware and see if it worked. If
                                it did, you assumed everything was copacetic. If not, you printed
                                a listing (at least the pages you were working on) and then traced
                                the program flow with the logic analyzer. Once you determined the
                                problem, you went back and edited your source again, repeating the
                                cycle. In a day, the most cycles I accomplished was probably four.

                                After discussion with another engineer, I wrote a monitor program
                                and developed some simple hardware to act as an emulator. Using
                                this emulator, I would copy the eprom to ram and run from there.
                                I could set breakpoints, examine registers and memory locations.
                                I could also hand-patch the code.

                                While building this emulator, my boss stopped by the bench and
                                asked me what I was doing. So, I told him. He was not terribly
                                happy and wanted to know how much longer I was going to waste on
                                this, but he let me continue. It took me a week to get the initial
                                functionality. In the two days following that, I made as much
                                progress on the actual project as I would normally accomplish in
                                a week. As I added features to the emulator, progress went even
                                faster.

                                It's like an optimization problem. You can only go so far by
                                making small tweaks. Sometimes you need to try a different
                                algorithm.

                                - George
                              • malekb@tce.com
                                Sorry about the delay... Comments below. ... the ... one of ... if all I ... middleware ... device. No ... so, ... each of ... Hmmm. ... middleware ... speak
                                Message 15 of 18 , Nov 5, 2001
                                • 0 Attachment
                                  Sorry about the delay...
                                  Comments below.

                                  --- In extremeprogramming@y..., kevinxp@q... wrote:
                                  > --- In extremeprogramming@y..., malekb@t... wrote:
                                  > > But what if all of this user level functionality is dependent on
                                  the
                                  > > same layer middleware layer such that it's no harder to do any
                                  one of
                                  > > these than the other?
                                  >
                                  > Wow. That would be some middleware layer. You're really saying that
                                  if all I
                                  > wanted was a channel 2 video and sound pass-through, that the
                                  middleware
                                  > would be identical to a complete set top box? Really? No input
                                  device. No
                                  > visual overlays above the image, so no font generator...
                                  >
                                  > > > Now, do you need drivers to display channel 2 without sound? If
                                  so,
                                  > > > there might be a way to break that story down. If not, then
                                  each of
                                  > > > these stories seems really incremental to me.
                                  > >
                                  > > What exactly do you mean by this?
                                  >
                                  > Which part?
                                  >
                                  > Can you break down the story of displaying channel 2 without sound?
                                  Hmmm.
                                  > Well, I've already implied that this story probably requires less
                                  middleware
                                  > (and fewer drivers) than you have suggested. If I'm wrong, please
                                  speak up.
                                  >
                                  > Could we break it down further? Sure, how about an output-only
                                  device:
                                  > Display a blank blue screen on the TV. How much infrastructure
                                  would that
                                  > take? How about lighting an LED (but not passing the signal
                                  through) when
                                  > there is a valid input signal? Or, forget the input/output and just
                                  support the
                                  > power on/off button on the front of the box.

                                  This sounds more like unit/integration testing. The way things are
                                  done in our environment is as follows -

                                  1) code is developed with little/no unit testing
                                  2) some sort of integration testing
                                  3) followed by heavy reliance on system test

                                  The other point that I forgot to mention is that system test is
                                  actually organized as an additional group that works closely with the
                                  development team. I'm not sure what this means from an iteration
                                  perspective. Should all iterations go through system test?


                                  >
                                  > Or were you asking about the incremental part?

                                  Yes I was. Should've been more specific.


                                  > I'm trying to break up the
                                  > functionality such that each story adds just a small amount of
                                  total code to
                                  > the system. The code might all be in one "layer" (see below), or it
                                  might be
                                  > a bit of code at the top, a bit in the middle, and a bit at the
                                  bottom.
                                  >
                                  > Hopefully, none of the stories require some HUGE infrastructure
                                  lump to be
                                  > developed all at once. In your sample, I would think that the main
                                  features
                                  > that *might* fall into this would be:
                                  > - passing video through
                                  > - passing sound through
                                  > - generating a non-text visual overlay
                                  > - generating text on screen
                                  > - accepting input from the front of the box
                                  > - accepting remote input
                                  > - accepting meta-information through the signal
                                  > - connecting to home base through a phone jack
                                  > - accepting meta-information through the phone jack
                                  >
                                  > But, by breaking them up into those very fine slices, hopefully the
                                  work of the
                                  > drivers and middleware layers could be spread out among multiple
                                  stories. This
                                  > has (at least) two big benefits:
                                  >
                                  > 1. You only code the middleware that you need, so the customer can
                                  choose
                                  > to omit some story and doesn't have to pay for stuff that isn't
                                  used.

                                  I think we need to get our customer (i.e. product
                                  managment/marketing) involved to this level of detail. They're not
                                  used to thinking this way. They usually let the software project
                                  lead provide status updates and manage progress/milestones internally.

                                  >
                                  > 2. You can evolve your design over time, learning as you go, rather
                                  than
                                  > guessing up front what you think the drivers and middleware should
                                  look like.

                                  Agreed. The problem becomes keeping developers from implementing
                                  more than what's called for in the current interation. Their
                                  tendency will be to implement the things for future iterations as
                                  well. Not sure how to counter this...


                                  >
                                  > > I don't know much about mock objects. It sounds like a
                                  > > stub/simulation method. How is it any different than just
                                  writing a
                                  > > stub?
                                  >
                                  > It's a stub with a specific purpose: Allow you to test and
                                  implement the higher
                                  > levels of the system. Usually they're used because a certain
                                  section of code
                                  > has a trait that makes it hard to test against the real thing, such
                                  as:
                                  > 1. Unpredictable (e.g. random number generator, network with
                                  traffic)
                                  > 2. Slow (e.g. database, printer, email)
                                  > 3. Hard/slow to set up for the test (e.g. database)
                                  > 4. Limited availability (e.g. rare (or non-existent) hardware)
                                  >
                                  > > My only concern is that there could be some resistance to
                                  > > doing something that is percieved as disposable later.
                                  >
                                  > Once you have a mock, you rarely dispose of it. It continues to
                                  serve an
                                  > important role as a test object throughout the life of the project.
                                  Near the
                                  > end, when you're fixing a bug in the upper layer, it's much faster
                                  to test
                                  > and validate your fix against a mock than against the actual target.


                                  I guess I need to get more information...
                                  What about the fidelity of the mock objects vs. the real thing? If
                                  it takes a significant amount of time to develop/debug the mock
                                  object, folks will choose to wait for the real hw/sw.


                                  >
                                  > > That's what has led to our layered development approach. We
                                  develop
                                  > > from the ground up so that the lower layers will be in place for
                                  the upper
                                  > > layers. This doesn't seem to lend itself to defining end-to-end
                                  user
                                  > > level stories, and that's what I'm trying to figure out...
                                  >
                                  > True. But someone mentioned, wouldn't the development of the
                                  drivers go
                                  > faster and smoother if the code they served was being written at
                                  the same
                                  > time?
                                  >
                                  > You're describing a traditional "horizontal" layered approach to
                                  building
                                  > software. XP works better with "vertical" slices through your
                                  system. It's
                                  > not always easy, but it's almost always possible. Of course, your
                                  domain
                                  > may be an exception...but I wouldn't bet on that.
                                  >
                                  > Eagerly awaiting your next posting...
                                  >
                                  > Kevin
                                • Jim.Hyslop
                                  ... It depends on your hardware constraints. If you re programming a PIC microprocessor, you might have as little as 2K of EPROM for your program, and a
                                  Message 16 of 18 , Nov 5, 2001
                                  • 0 Attachment
                                    Ron Jeffries <ronjeffries@...> wrote:
                                    > It's like this:
                                    > Console <---language---> program
                                    > which is implemented as
                                    > Console <---language--RS232--language---> program
                                    > that is, the RS232 just transmits "language" from place to place.
                                    >
                                    > Does that make sense?
                                    It depends on your hardware constraints. If you're programming a PIC
                                    microprocessor, you might have as little as 2K of EPROM for your program,
                                    and a maximum of 8 stack levels. The program would then not have the luxury
                                    of the abstraction layer.

                                    On the other hand, though, the OP has mentioned it's for a set-top box,
                                    which would likely have considerably more memory and horsepower, in which
                                    case I'd agree completely with the abstraction.

                                    --
                                    Jim
                                  • kevinxp@qualitycode.com
                                    ... I guess it depends on your terminology. The Customer Tests (aka Acceptance Tests) should be run at least at the end of every iteration. Ideally they should
                                    Message 17 of 18 , Nov 9, 2001
                                    • 0 Attachment
                                      --- In extremeprogramming@y..., malekb@t... wrote:
                                      > --- In extremeprogramming@y..., kevinxp@q... wrote:
                                      > This sounds more like unit/integration testing. The way things are
                                      > done in our environment is as follows -
                                      >
                                      > 1) code is developed with little/no unit testing
                                      > 2) some sort of integration testing
                                      > 3) followed by heavy reliance on system test
                                      >
                                      > The other point that I forgot to mention is that system test is
                                      > actually organized as an additional group that works closely with
                                      > the development team. I'm not sure what this means from an
                                      > iteration perspective. Should all iterations go through system
                                      > test?

                                      I guess it depends on your terminology. The Customer Tests (aka
                                      Acceptance Tests) should be run at least at the end of every
                                      iteration. Ideally they should be run much more often--perhaps daily.

                                      Do you think it would be better to catch more problems in integration
                                      testing (which I'm guessing is comparable to Customer Tests) than to
                                      rely so much on system testing?

                                      Do you think it would be better to catch more problems in Programmer
                                      Tests (unit tests) than during the Customer Tests?

                                      If so, you would probably want to increase your testing efforts in
                                      the earlier areas.

                                      > > This has (at least) two big benefits:
                                      > >
                                      > > 1. You only code the middleware that you need, so the customer
                                      > > can choose to omit some story and doesn't have to pay for stuff
                                      > > that isn't used.
                                      >
                                      > I think we need to get our customer (i.e. product
                                      > managment/marketing) involved to this level of detail. They're not
                                      > used to thinking this way. They usually let the software project
                                      > lead provide status updates and manage progress/milestones
                                      > internally.

                                      Yes. XP thrives on communication, visibility, and allowing the
                                      Customer to make decisions about what features should be developed
                                      when.

                                      Imagine a customer who needs the box by a certain date. As the date
                                      approaches, the customer is given the option to ship a box that is
                                      perfect EXCEPT that one low-priority feature hasn't even been
                                      started. Wouldn't that be better than the traditional options of
                                      slipping the date or shipping a box that is not fully tested or
                                      debugged?

                                      > > 2. You can evolve your design over time, learning as you go,
                                      > > rather than guessing up front what you think the drivers and
                                      > > middleware should look like.
                                      >
                                      > Agreed. The problem becomes keeping developers from implementing
                                      > more than what's called for in the current interation. Their
                                      > tendency will be to implement the things for future iterations as
                                      > well. Not sure how to counter this...

                                      Pairing, coaching, and breaking the project into very small tasks. If
                                      a developer has a card for a single task, s/he is more likely to stay
                                      focused on that task. It does take discipline and peer pressure.

                                      > I guess I need to get more information...
                                      > What about the fidelity of the mock objects vs. the real thing? If
                                      > it takes a significant amount of time to develop/debug the mock
                                      > object, folks will choose to wait for the real hw/sw.

                                      Most of my mock objects are less than 30 lines of code. Since they
                                      are created bit-by-bit, as needed, to support specific tests and
                                      specific functionality, they are very quick to develop.

                                      Kevin
                                    Your message has been successfully submitted and would be delivered to recipients shortly.