Perhaps we should take a cue from Volkswagen and call it
"Research *then* Development"
George
Good point - I'm going to copy that one.
If we knew what we were doing, we won't call it "research".
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..... Forth based HIDECS Consultancy............. Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
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.
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
------------------------------------------------------
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 8-)
George
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..... Forth based HIDECS Consultancy............. Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA.
"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.
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.
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:
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
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..... Forth based HIDECS Consultancy............. Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
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
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)
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
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.
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
research and Development.
little "r" and big "D"
--------------------------------------- Posted through
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.