1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

OT: Research and Development

Discussion in 'Embedded' started by George Neuner, May 26, 2014.

  1. Perhaps we should take a cue from Volkswagen and call it

    "Research *then* Development"

    George
     
    George Neuner, May 26, 2014
    #1
    1. Advertisements

  2. George Neuner

    David Brown Guest

    Good point - I'm going to copy that one.

    If we knew what we were doing, we won't call it "research".
     
    David Brown, May 26, 2014
    #2
    1. Advertisements

  3. George Neuner

    Tom Gardner Guest

    How very 20th century.

    Nowadays everything has to he "agile" or "extreme",
    regardless of the degree to which it makes sense for
    any specific development :(
     
    Tom Gardner, May 26, 2014
    #3
  4. If you want your systems to have real integrity you would drop the agile
    approach like a hot brick and learn to be more adept at the early
    development of sound requirements that are testable for compliance with the
    clients real needs before you launch into writing the design specification.
    Also, remember that prototyping is only meant to be a tool for exploring the
    requirements space in order to hone the thinking at that level. The two best
    models of development still tend to be either the "V" model or Barry Boehm's
    Spiral Model (applied properly).

    Wernher von Braun once said "Research is what I am doing when I do not know
    what I am doing". So, to say you are involved in R&D must mean that you are
    on a voyage to discover what your client truly needs in a way that he can
    sign his full agreement with your proposal. You might spend more than 60% of
    project time getting to the stage that the requirements become complete and
    testable, but, in the long run it is often much faster and yields better
    quality of product than the agile methods seem to have done.

    --
    ********************************************************************
    Paul E. Bennett IEng MIET.....<email://>
    Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
    Mob: +44 (0)7811-639972
    Tel: +44 (0)1235-510979
    Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
    ********************************************************************
     
    Paul E Bennett, May 26, 2014
    #4
  5. George Neuner

    Tom Gardner Guest

    While I have considerable sympathy for that, it is too simplistic: there are
    cases where agile is appropriate.

    In particular, consider where
    - it is an elaboration or recapitulation of previous designs (many
    developments fall into this category)
    - the client doesn't know the requirements (effectively it is research)
    - the client cannot reasonably articulate the requirements (temporary lack of
    availability, or it is easier to show'n'tell)
    - the client unreasonably cannot articulate the requirements but
    "will know it when they see it"

    Having spent most of my professional life in industrial and
    contract R&D, I entirely agree. But that isn't the whole world.
     
    Tom Gardner, May 26, 2014
    #5
  6. Hah, nice phrase, but not universally applicable - sometimes
    we do research, then we have to do some development in order
    to be able to continue with the research.

    Life can be complicated :) .

    Dimiter
     
    Dimiter_Popoff, May 26, 2014
    #6
  7. It was a play on David's words based on a Volkswagen commercial:


    It seems as if very few others saw it (maybe US only).
    David, at least, seemed to get the joke :cool:

    George
     
    George Neuner, May 27, 2014
    #7
  8. Sometimes Simple" is preferred.
    True, but that is no reason not to do properly formed requirements for the
    upgrading step. The upgrade requirements specification can still be
    testable. Done plenty of that with big science research projects.

    Which is where some prototype exploration is useful and probably the only
    place that agile methods may work well. However, the output of that could
    easily be a proper, testable requirements specification.
    Likewise, I have been both sides of the industrial and contracted into big
    science research.


    ********************************************************************
    Paul E. Bennett IEng MIET.....<email://>
    Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
    Mob: +44 (0)7811-639972
    Tel: +44 (0)1235-510979
    Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
    ********************************************************************
     
    Paul E Bennett, May 27, 2014
    #8
  9. George Neuner

    Tom Gardner Guest

    "Everything should be as simple as possible - but no simpler"

    I've seen organisations descend into completely unnecessary "paralysis
    through analysis". Yes, the organisation was dysfunctional, but in
    such cases XP/extreme can be a way of cutting through the crap.

    The trouble is that such dysfunctional organisations typically
    think following a tick-box process is sufficient. Probably they will
    try to apply XP/extreme everywhere, whether or not it is appropriate,
    simply because it worked once. And IMHO the religious zealotry of
    XP is its least attractive aspect.

    But that doesn't invalidate XP/extreme under *appropriate* circumstances.

    /Sometimes/ that's too heavyweight and unnecessary.

    The trick is to have many tools in your toolbox, *and* know
    when to use/ignore each tool.

    There are no silver bullets, whatever the religious dogma
    of any design methodology.
     
    Tom Gardner, May 27, 2014
    #9
  10. Rom Gardner:

    "There are no silver bullets, whatever the religious dogma
    of any design methodology."


    Yes, platitudes can provide temporary comfort, but in the end, it's
    a struggle by the individual to achieve a goal. A clean determination
    apart from the labyrinthes of success and defeat is called for.
     
    haiticare2011, May 27, 2014
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.