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

Re: [XP] Defining stories in an embedded system

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.