On Fri, 23 May 2014 16:21:46 +0200, David Brown <david.brown@hesbynett.no> wrote:>There is a reason this stuff is called "Research and Development". Do >the research, then you can start of the development.Perhaps we should take a cue from Volkswagen and call it "Research *then* Development" George
OT: Research and Development
Started by ●May 26, 2014
Reply by ●May 26, 20142014-05-26
On 26/05/14 06:17, George Neuner wrote:> On Fri, 23 May 2014 16:21:46 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> There is a reason this stuff is called "Research and Development". Do >> the research, then you can start of the development. > > Perhaps we should take a cue from Volkswagen and call it > > "Research *then* Development" >Good point - I'm going to copy that one. If we knew what we were doing, we won't call it "research".
Reply by ●May 26, 20142014-05-26
On 26/05/14 05:17, George Neuner wrote:> On Fri, 23 May 2014 16:21:46 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> There is a reason this stuff is called "Research and Development". Do >> the research, then you can start of the development. > > Perhaps we should take a cue from Volkswagen and call it > > "Research *then* Development"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 :(
Reply by ●May 26, 20142014-05-26
Tom Gardner wrote:> On 26/05/14 05:17, George Neuner wrote: >> On Fri, 23 May 2014 16:21:46 +0200, David Brown >> <david.brown@hesbynett.no> wrote: >> >>> There is a reason this stuff is called "Research and Development". Do >>> the research, then you can start of the development. >> >> Perhaps we should take a cue from Volkswagen and call it >> >> "Research *then* Development" > > 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 :(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://Paul_E.Bennett@topmail.co.uk> 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.. ********************************************************************
Reply by ●May 26, 20142014-05-26
On 26/05/14 09:40, Paul E Bennett wrote:> Tom Gardner wrote: > >> On 26/05/14 05:17, George Neuner wrote: >>> On Fri, 23 May 2014 16:21:46 +0200, David Brown >>> <david.brown@hesbynett.no> wrote: >>> >>>> There is a reason this stuff is called "Research and Development". Do >>>> the research, then you can start of the development. >>> >>> Perhaps we should take a cue from Volkswagen and call it >>> >>> "Research *then* Development" >> >> 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 :( > > 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).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"> 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.Having spent most of my professional life in industrial and contract R&D, I entirely agree. But that isn't the whole world.
Reply by ●May 26, 20142014-05-26
On 26.5.2014 г. 07:17, George Neuner wrote:> On Fri, 23 May 2014 16:21:46 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> There is a reason this stuff is called "Research and Development". Do >> the research, then you can start of the development. > > Perhaps we should take a cue from Volkswagen and call it > > "Research *then* Development" > > George >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, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by ●May 27, 20142014-05-27
On Mon, 26 May 2014 22:11:46 +0300, Dimiter_Popoff <dp@tgi-sci.com> wrote:>On 26.5.2014 ?. 07:17, George Neuner wrote: >> >> Perhaps we should take a cue from Volkswagen and call it >> >> "Research *then* Development" > >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 :-) .It was a play on David's words based on a Volkswagen commercial: https://www.youtube.com/watch?v=5GVEXyerBl0 It seems as if very few others saw it (maybe US only). David, at least, seemed to get the joke 8-) George
Reply by ●May 27, 20142014-05-27
Tom Gardner wrote:> On 26/05/14 09:40, Paul E Bennett wrote: >> Tom Gardner wrote:[%X]>>> Nowadays everything has to he "agile" or "extreme", >>> regardless of the degree to which it makes sense for >>> any specific development :( >> >> 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). > > While I have considerable sympathy for that, it is too simplistic: there > are cases where agile is appropriate.Sometimes Simple" is preferred.> In particular, consider where > - it is an elaboration or recapitulation of previous designs (many > developments fall into this category)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.> - 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"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.>> 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. > > Having spent most of my professional life in industrial and > contract R&D, I entirely agree. But that isn't the whole world.Likewise, I have been both sides of the industrial and contracted into big science research. ******************************************************************** Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk> 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.. ********************************************************************
Reply by ●May 27, 20142014-05-27
On 27/05/14 10:12, Paul E Bennett wrote:> Tom Gardner wrote: > >> On 26/05/14 09:40, Paul E Bennett wrote: >>> Tom Gardner wrote: > > [%X] > >>>> Nowadays everything has to he "agile" or "extreme", >>>> regardless of the degree to which it makes sense for >>>> any specific development :( >>> >>> 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). >> >> While I have considerable sympathy for that, it is too simplistic: there >> are cases where agile is appropriate. > > Sometimes Simple" is preferred."Everything should be as simple as possible - but no simpler">> In particular, consider where >> - it is an elaboration or recapitulation of previous designs (many >> developments fall into this category) > > 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.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.>> - 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" > > 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./Sometimes/ that's too heavyweight and unnecessary.>>> 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. >> >> Having spent most of my professional life in industrial and >> contract R&D, I entirely agree. But that isn't the whole world. > > Likewise, I have been both sides of the industrial and contracted into big > science research.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.
Reply by ●May 27, 20142014-05-27
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.
