OT: Research and Development

On 27/05/14 11:56, haiticare2011@gmail.com wrote:
> 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.

Determination and struggle are necessary but not sufficient.

Mature engineering judgement is necessary.

Paul E Bennett <Paul_E.Bennett@topmail.co.uk> writes:

> 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). 

I am not familiar with those models, but I agree with your sentiment! I
do not like the agile paradigm. It seems to me that mode of development
has become prevalent for two reasons:

  1. It is easier for people who have limited ability to think and
  reason abstractly.

  2. It satiates mistrustful managers.

Having said that, I also know that, while complete up front requirements
definition is the idea, it is often not possible or feasible and that
there is almost always some "back and forth" on the requirements and
system functions as the system development progresses.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Randy Yates wrote:

> Paul E Bennett <Paul_E.Bennett@topmail.co.uk> writes:
> 
>> 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).
> 
> I am not familiar with those models, but I agree with your sentiment! I
> do not like the agile paradigm. It seems to me that mode of development
> has become prevalent for two reasons:
> 
>   1. It is easier for people who have limited ability to think and
>   reason abstractly.
> 
>   2. It satiates mistrustful managers.
> 
> Having said that, I also know that, while complete up front requirements
> definition is the idea, it is often not possible or feasible and that
> there is almost always some "back and forth" on the requirements and
> system functions as the system development progresses.

The V model is shown in IEC6108, amongst other places. A description of the  
Barry Boehm Sprial Model is on Wikipedia. 

Chris Hills of Phaedrus Systems has recently presented some very telling 
figures about the having decent requirements specs at the start against not 
having them an the results are quite telling. Correcting wrong directions 
late in a project gets very expensive in time, money and integrity.

-- 
********************************************************************
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..
********************************************************************

Paul E Bennett wrote:
> Randy Yates wrote:
>
>> Paul E Bennett <Paul_E.Bennett@topmail.co.uk> writes:
>>
>>> 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).
>>
>> I am not familiar with those models, but I agree with your sentiment! I
>> do not like the agile paradigm. It seems to me that mode of development
>> has become prevalent for two reasons:
>>
>>    1. It is easier for people who have limited ability to think and
>>    reason abstractly.
>>
>>    2. It satiates mistrustful managers.
>>
>> Having said that, I also know that, while complete up front requirements
>> definition is the idea, it is often not possible or feasible and that
>> there is almost always some "back and forth" on the requirements and
>> system functions as the system development progresses.
>
> The V model is shown in IEC6108, amongst other places. A description of the
> Barry Boehm Sprial Model is on Wikipedia.
>
> Chris Hills of Phaedrus Systems has recently presented some very telling
> figures about the having decent requirements specs at the start against not
> having them an the results are quite telling. Correcting wrong directions
> late in a project gets very expensive in time, money and integrity.
>


I don't consider Agile to be synonymous with "working without 
requirements". It's more a matter of trying to organize activities
such that requirements are more ... fungible as trades become better
in focus.

-- 
Les Cargill

On 29/05/14 00:39, Paul E Bennett wrote:
> Randy Yates wrote:
>
>> Paul E Bennett <Paul_E.Bennett@topmail.co.uk> writes:
>>
>>> 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).
>>
>> I am not familiar with those models, but I agree with your sentiment! I
>> do not like the agile paradigm. It seems to me that mode of development
>> has become prevalent for two reasons:
>>
>>    1. It is easier for people who have limited ability to think and
>>    reason abstractly.
>>
>>    2. It satiates mistrustful managers.
>>
>> Having said that, I also know that, while complete up front requirements
>> definition is the idea, it is often not possible or feasible and that
>> there is almost always some "back and forth" on the requirements and
>> system functions as the system development progresses.
>
> The V model is shown in IEC6108, amongst other places. A description of the
> Barry Boehm Sprial Model is on Wikipedia.
>
> Chris Hills of Phaedrus Systems has recently presented some very telling
> figures about the having decent requirements specs at the start against not
> having them an the results are quite telling. Correcting wrong directions
> late in a project gets very expensive in time, money and integrity.

That's just as "religious" as the XP/agile proponents'
statements - and just as (in)valid.

Use a hacksaw to cut metal. Use a ripsaw to cut wood.
Distrust those who claim a ripsaw is best at making cuts,
even if they show you perfectly cut blocks of wood.

Consider the cases in which:
   - time/money is fixed and limited, and implementing 60% of the
     total solution is useful and more useful than 50% of them
   - the exact amount of effort required for each 1% of the
     individual requirements is not knowable
   - you have a "customer" who can answer any question the team
     asks instantly available
and particularly
   - where the requirements /legitimately/ vary over the course
     of the project (e.g. if the other party manages/fails to do X
     then we do Y else Z)

On Monday, May 26, 2014 12:17:06 AM UTC-4, 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

I think this thread has gone onto an area of "innovation theory." Steve Jobs
said he was influenced by "The Innovators Dilemma," by Clayton Christensen, 
a Harvard Business Professor. The Cliff Notes version is that innovation  comes
out of unpredictable, left-field directions, often, whereas companies try to 
do their thing with constant improvement. Therefore the dilemma.

He has written about 10 of these books on various topics related.

The OP quote came from my quest to find a fast ADC capability, the responses 
for which I want to thank everyone. At this point, a $1000 board from Cyber 
Research looks good, but I wanted to understand the design of such systems. 

I still don't know, to my satisfaction, and I suspect that a dual-port memory 
approach is one aspect. 

In any case, a constant temptation is to "hijack" current systems as much as 
possible to avoid design work. (Current arch's seem pointed at VR gamer apps.) 

So at this point I am looking for information on designing memory buffer 
systems. The idea is that a front end mcu  fills a two-part buffer which is 
sequentially read by a storage machine for long term storage. While one memory 
area is being filled, the other is being read. 

jb

On Sat, 31 May 2014 06:09:01 -0700 (PDT), haiticare2011@gmail.com
wrote:

>The OP quote came from my quest to find a fast ADC capability, the responses 
>for which I want to thank everyone. At this point, a $1000 board from Cyber 
>Research looks good, but I wanted to understand the design of such systems. 
>
>I still don't know, to my satisfaction, and I suspect that a dual-port memory 
>approach is one aspect. 

My take from the previous thread is that you are still in the
"requirements analysis" phase and don't really know what throughput
you really will need.

It's pretty useless to evaluate boards until you get a better handle
on how much data you are dealing with.


>In any case, a constant temptation is to "hijack" current systems as much as 
>possible to avoid design work. (Current arch's seem pointed at VR gamer apps.) 

It is quite appropriate to "leverage" existing (sub)systems and
software as much as is possible, but that does not substitute for
design work ... you still have to decide whether something is adequate
for your need and how - or even whether - it can be integrated into
your system.

George

>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
>


research and Development.


little "r" and big "D"

	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com