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

Defining stories in an embedded system

Expand Messages
  • malekb@tce.com
    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
    Message 1 of 18 , Nov 1, 2001
    • 0 Attachment
      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.

      Thanks,
      Baher
    • 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 2 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 3 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 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?
            >
            > 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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.