I'm trying to think of a good example of where there may be a distinct and valid tradeoff between the cost to develop some technology versus the cost to deploy it. This is for a book chapter on systems design that I'm almost finished writing. The point of the example is to get people familiar with the concept of questioning their assumptions about how much things will cost when they start designing for markets that are markedly different for the ones that they are accustomed to working in. In this case I'm classifying "development" costs as, basically, the NRE costs involved in making the technology work, and the "deployment" costs as the costs involved in putting the technology into the hands of the people who are going to actually use it. Examples would be talking by radio vs. talking by phone, or traveling by car (with a road system) vs. traveling by air. Unfortunately, the examples that I'm coming up with all have other obvious tradeoffs that overshadow the develop vs. deploy one, or they have not-so-obvious development costs (for instance it's far easier to develop a phone line to go across town than it is to design a radio transceiver, but if you want to develop a phone _system_ that includes long distance and millions of subscribers, then you've got a lot more development effort than you would for a radio transceiver, etc.). Suggestions welcome. I'm at the point of just throwing up my hands and not trying to cite any specific cases, or to change the underlying target of the example somehow -- posibly to per-user cost vs. deployment, or something like that. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Deployment vs. Development Costs
Started by ●October 8, 2013
Reply by ●October 8, 20132013-10-08
On 10/08/2013 01:23 PM, Tim Wescott wrote:> I'm trying to think of a good example of where there may be a distinct > and valid tradeoff between the cost to develop some technology versus the > cost to deploy it. > > This is for a book chapter on systems design that I'm almost finished > writing. The point of the example is to get people familiar with the > concept of questioning their assumptions about how much things will cost > when they start designing for markets that are markedly different for the > ones that they are accustomed to working in. > > In this case I'm classifying "development" costs as, basically, the NRE > costs involved in making the technology work, and the "deployment" costs > as the costs involved in putting the technology into the hands of the > people who are going to actually use it. > > Examples would be talking by radio vs. talking by phone, or traveling by > car (with a road system) vs. traveling by air. > > Unfortunately, the examples that I'm coming up with all have other > obvious tradeoffs that overshadow the develop vs. deploy one, or they > have not-so-obvious development costs (for instance it's far easier to > develop a phone line to go across town than it is to design a radio > transceiver, but if you want to develop a phone _system_ that includes > long distance and millions of subscribers, then you've got a lot more > development effort than you would for a radio transceiver, etc.). > > Suggestions welcome. I'm at the point of just throwing up my hands and > not trying to cite any specific cases, or to change the underlying target > of the example somehow -- posibly to per-user cost vs. deployment, or > something like that. >On-orbit servicing of satellites. The payloads have to be man-rated, but you can replace propellant, gyros, and so on. Another example is GPS. It works better than Loran did, and the receivers are cheaper, but the infrastructure is $$$$. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by ●October 8, 20132013-10-08
In comp.dsp Tim Wescott <tim@seemywebsite.really> wrote:> I'm trying to think of a good example of where there may be a distinct > and valid tradeoff between the cost to develop some technology versus the > cost to deploy it.(snip)> Examples would be talking by radio vs. talking by phone, or traveling by > car (with a road system) vs. traveling by air.> Unfortunately, the examples that I'm coming up with all have other > obvious tradeoffs that overshadow the develop vs. deploy one, or they > have not-so-obvious development costs (for instance it's far easier to > develop a phone line to go across town than it is to design a radio > transceiver, but if you want to develop a phone _system_ that includes > long distance and millions of subscribers, then you've got a lot more > development effort than you would for a radio transceiver, etc.).I don't know if this will help, but it reminds me of MCI. As well as I remember the story, they had microwave links to allow truckers to communicate. When they had enough such links, someone figured out that they could use it for a long distance phone system. Designing and deploying a long distance phone system for millions, or 10s of millions of customers from the start likely isn't easy, but building on an existing system isn't so hard. The problem is always knowing how fast to scale up. If you have a sudden large demand, you need to build up fast, but then you might overshoot the demand and waste a lot of money on unneeded infrastructure. Getting a little farther off the subject, there was some years ago a major internet outage in So. Cal. For redundancy, there were links leased from, if I remember, both ATT and MCI, so there shouldn't have been a problem. But it turned out that for at least some part of the link one of them leased fiber from the other, and a backhoe went through the fibers on that link. That is, the one place where there wasn't redundancy. But competition and redundancy might not be part of the discussion. -- glen
Reply by ●October 8, 20132013-10-08
On Wednesday, October 9, 2013 6:23:16 AM UTC+13, Tim Wescott wrote:> I'm trying to think of a good example of where there may be a distinct > > and valid tradeoff between the cost to develop some technology versus the > > cost to deploy it. > > > > This is for a book chapter on systems design that I'm almost finished > > writing. The point of the example is to get people familiar with the > > concept of questioning their assumptions about how much things will cost > > when they start designing for markets that are markedly different for the > > ones that they are accustomed to working in. > > > > In this case I'm classifying "development" costs as, basically, the NRE > > costs involved in making the technology work, and the "deployment" costs > > as the costs involved in putting the technology into the hands of the > > people who are going to actually use it. > > > > Examples would be talking by radio vs. talking by phone, or traveling by > > car (with a road system) vs. traveling by air. > > > > Unfortunately, the examples that I'm coming up with all have other > > obvious tradeoffs that overshadow the develop vs. deploy one, or they > > have not-so-obvious development costs (for instance it's far easier to > > develop a phone line to go across town than it is to design a radio > > transceiver, but if you want to develop a phone _system_ that includes > > long distance and millions of subscribers, then you've got a lot more > > development effort than you would for a radio transceiver, etc.). > > > > Suggestions welcome. I'm at the point of just throwing up my hands and > > not trying to cite any specific cases, or to change the underlying target > > of the example somehow -- posibly to per-user cost vs. deployment, or > > something like that. > > > > -- > > > > Tim Wescott > > Wescott Design Services > > http://www.wescottdesign.comDon't forget sustainability and climate change or it won't get published!
Reply by ●October 8, 20132013-10-08
On Tue, 08 Oct 2013 13:22:53 -0700, gyansorova wrote:> On Wednesday, October 9, 2013 6:23:16 AM UTC+13, Tim Wescott wrote: >> I'm trying to think of a good example of where there may be a distinct >> >> and valid tradeoff between the cost to develop some technology versus >> the >> >> cost to deploy it. >> >> >> >> This is for a book chapter on systems design that I'm almost finished >> >> writing. The point of the example is to get people familiar with the >> >> concept of questioning their assumptions about how much things will >> cost >> >> when they start designing for markets that are markedly different for >> the >> >> ones that they are accustomed to working in. >> >> >> >> In this case I'm classifying "development" costs as, basically, the NRE >> >> costs involved in making the technology work, and the "deployment" >> costs >> >> as the costs involved in putting the technology into the hands of the >> >> people who are going to actually use it. >> >> >> >> Examples would be talking by radio vs. talking by phone, or traveling >> by >> >> car (with a road system) vs. traveling by air. >> >> >> >> Unfortunately, the examples that I'm coming up with all have other >> >> obvious tradeoffs that overshadow the develop vs. deploy one, or they >> >> have not-so-obvious development costs (for instance it's far easier to >> >> develop a phone line to go across town than it is to design a radio >> >> transceiver, but if you want to develop a phone _system_ that includes >> >> long distance and millions of subscribers, then you've got a lot more >> >> development effort than you would for a radio transceiver, etc.). >> >> >> >> Suggestions welcome. I'm at the point of just throwing up my hands and >> >> not trying to cite any specific cases, or to change the underlying >> target >> >> of the example somehow -- posibly to per-user cost vs. deployment, or >> >> something like that. >> >> >> >> -- >> >> >> >> Tim Wescott >> >> Wescott Design Services >> >> http://www.wescottdesign.com > > Don't forget sustainability and climate change or it won't get > published!Please don't go there. My editor has already gone and replaced "English" (as in "speaking English vs. speaking Business") with "English or your local language". I figure that anyone who's smart enough to get anything out of the chapter will be able to understand that if the work is in English, and it says "English" as opposed to "business jargon", then if they speak Urdu they can substitute "Urdu" for English, and if they speak Navaho they can substitute "Navaho" for "English", and if they're fresh off the saucer from *$^%# and they speak @#$^&*%!!* then -- well, you get the idea. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●October 8, 20132013-10-08
"Tim Wescott"> > I'm trying to think of a good example of where there may be a distinct > and valid tradeoff between the cost to develop some technology versus the > cost to deploy it.** The lack of obvious examples indicates your notion is essentially false.> This is for a book chapter on systems design that I'm almost finished > writing. The point of the example is to get people familiar with the > concept of questioning their assumptions about how much things will cost > when they start designing for markets that are markedly different for the > ones that they are accustomed to working in. > > In this case I'm classifying "development" costs as, basically, the NRE > costs involved in making the technology work, and the "deployment" costs > as the costs involved in putting the technology into the hands of the > people who are going to actually use it. > > Examples would be talking by radio vs. talking by phone, or traveling by > car (with a road system) vs. traveling by air. > > Unfortunately, the examples that I'm coming up with all have other > obvious tradeoffs that overshadow the develop vs. deploy one, or they > have not-so-obvious development costs (for instance it's far easier to > develop a phone line to go across town than it is to design a radio > transceiver, but if you want to develop a phone _system_ that includes > long distance and millions of subscribers, then you've got a lot more > development effort than you would for a radio transceiver, etc.). > > Suggestions welcome. I'm at the point of just throwing up my hands and > not trying to cite any specific cases, or to change the underlying target > of the example somehow -- posibly to per-user cost vs. deployment, or > something like that.** How about the light bulb ? .... Phil
Reply by ●October 8, 20132013-10-08
On Wed, 09 Oct 2013 11:13:43 +1100, Phil Allison wrote:> "Tim Wescott" >> >> I'm trying to think of a good example of where there may be a distinct >> and valid tradeoff between the cost to develop some technology versus >> the cost to deploy it. > > ** The lack of obvious examples indicates your notion is essentially > false.Either that or I'm too dumb to know one -- but I think you're right.>> This is for a book chapter on systems design that I'm almost finished >> writing. The point of the example is to get people familiar with the >> concept of questioning their assumptions about how much things will >> cost when they start designing for markets that are markedly different >> for the ones that they are accustomed to working in. >> >> In this case I'm classifying "development" costs as, basically, the NRE >> costs involved in making the technology work, and the "deployment" >> costs as the costs involved in putting the technology into the hands of >> the people who are going to actually use it. >> >> Examples would be talking by radio vs. talking by phone, or traveling >> by car (with a road system) vs. traveling by air. >> >> Unfortunately, the examples that I'm coming up with all have other >> obvious tradeoffs that overshadow the develop vs. deploy one, or they >> have not-so-obvious development costs (for instance it's far easier to >> develop a phone line to go across town than it is to design a radio >> transceiver, but if you want to develop a phone _system_ that includes >> long distance and millions of subscribers, then you've got a lot more >> development effort than you would for a radio transceiver, etc.). >> >> Suggestions welcome. I'm at the point of just throwing up my hands and >> not trying to cite any specific cases, or to change the underlying >> target of the example somehow -- posibly to per-user cost vs. >> deployment, or something like that. > > ** How about the light bulb ?We decided to just leave it out. That made it easy. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●October 8, 20132013-10-08
On Tue, 08 Oct 2013 13:41:38 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>On 10/08/2013 01:23 PM, Tim Wescott wrote: >> I'm trying to think of a good example of where there may be a distinct >> and valid tradeoff between the cost to develop some technology versus the >> cost to deploy it. >> >> This is for a book chapter on systems design that I'm almost finished >> writing. The point of the example is to get people familiar with the >> concept of questioning their assumptions about how much things will cost >> when they start designing for markets that are markedly different for the >> ones that they are accustomed to working in. >> >> In this case I'm classifying "development" costs as, basically, the NRE >> costs involved in making the technology work, and the "deployment" costs >> as the costs involved in putting the technology into the hands of the >> people who are going to actually use it. >> >> Examples would be talking by radio vs. talking by phone, or traveling by >> car (with a road system) vs. traveling by air. >> >> Unfortunately, the examples that I'm coming up with all have other >> obvious tradeoffs that overshadow the develop vs. deploy one, or they >> have not-so-obvious development costs (for instance it's far easier to >> develop a phone line to go across town than it is to design a radio >> transceiver, but if you want to develop a phone _system_ that includes >> long distance and millions of subscribers, then you've got a lot more >> development effort than you would for a radio transceiver, etc.). >> >> Suggestions welcome. I'm at the point of just throwing up my hands and >> not trying to cite any specific cases, or to change the underlying target >> of the example somehow -- posibly to per-user cost vs. deployment, or >> something like that. >> > >On-orbit servicing of satellites. The payloads have to be man-rated, >but you can replace propellant, gyros, and so on. > >Another example is GPS. It works better than Loran did, and the >receivers are cheaper, but the infrastructure is $$$$.Not a great example. LORAN died of terminal neglect, not technical deficiency. Electronically and computationally, LORAN receivers (were much simpler than GPS receivers, ranging from the frequency bands used, to the received power, to the calculations. That very few units were being built killed the economics. While GPS provides better accuracy than basic LORAN, the long planned (but never fulfilled) eLORAN upgrade would have put LORAN in the same ballpark as basic GPS (~10m resolution), at modest cost to upgrade the transmission chains, and moderate increase in complexity of the receivers (although still simpler than GPS receivers). But even unenhanced LORAN (~400m) would have been plenty to get you to a port or airport. Given the significant (near) single point vulnerabilities of all of the satnav systems, many people thought LORAN made an almost perfect backup system - cheap (killing it saved a reported $190m over five years, which would have included the eLORAN upgrade - you couldn't get a single GPS bird into orbit for that), much more resistant to jamming (typically signals were something like *50db* stronger at the receiver*, and GPS jammers are everywhere today), and a totally different technology, with totally different points of failure, and essentially complete independence from GPS. And given the CPU requirements of GPS, adding LORAN to a GPS receiver would have been possible in many cases with just an add-on RF module. Instead LORAN was just barely kept alive (and shutdowns were attempted several times), so of course no one built hardware to use it. And then finally one of the justifications to finally shut it down was that usage was minimal. And it's far from clear that the current (US) GPS system is going to maintain a full complement of satellites over the next 15 years, given likely retirement rates (most of the active birds are operating well beyond their design lifetimes already), and the rate of replacement launches (the latter being impacted by numerous development delays and funding issues). At least GLONASS is back online, and we may see Galileo and Compass** online by 2020, so we'll have some redundancy there if the application needs it. Sorry, this is a bit of a hobbyhorse for me... *While that's hardly jam-proof, the resulting increase in power requirements would require massive (and thus easy to find) jammers, or very short effective ranges. Consider a typical (small) 100kw LORAN-C transmitter. The rule of thumb is that the jammer needs to get ~20db more noise to the receiver than the actual signal in order to effective jam the receiver - so a 100kw(!!) jammer would manage to jam only a 100 mile radius near the outskirts of a chain's normal reception area (~1000mi). That same 100 mile jamming circle would take on the order of *one* watt for GPS. The North Korean's are intermittently jamming GPS over half of South Korea with a few dozen watts. **The global version of Compass, that is - the regional system (aka Beidou) has been fully operational for a couple of years now, which is great if you live near China.
Reply by ●October 8, 20132013-10-08
Hi Robert, On 10/8/2013 7:33 PM, Robert Wessel wrote:> On Tue, 08 Oct 2013 13:41:38 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote:>> On-orbit servicing of satellites. The payloads have to be man-rated, >> but you can replace propellant, gyros, and so on. >> >> Another example is GPS. It works better than Loran did, and the >> receivers are cheaper, but the infrastructure is $$$$. > > Not a great example. LORAN died of terminal neglect, not technical > deficiency. Electronically and computationally, LORAN receivers (were > much simpler than GPS receivers, ranging from the frequency bands > used, to the received power, to the calculations.Agreed. With the sort of horsepower available for a dollar or two nowadays, you could track every GRI on the *globe* (if you could get signal from each) and still have CPU left to play a decent game of chess!> That very few units > were being built killed the economics. While GPS provides better > accuracy than basic LORAN, the long planned (but never fulfilled) > eLORAN upgrade would have put LORAN in the same ballpark as basic GPS > (~10m resolution), at modest cost to upgrade the transmission chains, > and moderate increase in complexity of the receivers (although still > simpler than GPS receivers). But even unenhanced LORAN (~400m) would > have been plenty to get you to a port or airport.Depending on GDoP, LORAN could get accuracies on the order of 200m and precisions closer to 20m! Close enough for a fisherman to find a lobsterpot he dropped the day before... In those regions where multiple GRI are accessible, I suspect it would be relatively easy to improve on this (as well as resolving tome of the "ambiguous" TD pairs that occur on a single GRI).> Given the significant (near) single point vulnerabilities of all of > the satnav systems, many people thought LORAN made an almost perfect > backup system - cheap (killing it saved a reported $190m over five > years, which would have included the eLORAN upgrade - you couldn't get > a single GPS bird into orbit for that), much more resistant to jamming > (typically signals were something like *50db* stronger at the > receiver*, and GPS jammers are everywhere today), and a totally > different technology, with totally different points of failure, and > essentially complete independence from GPS. And given the CPU > requirements of GPS, adding LORAN to a GPS receiver would have been > possible in many cases with just an add-on RF module.The antenna may be an issue...> Instead LORAN was just barely kept alive (and shutdowns were attempted > several times), so of course no one built hardware to use it. And > then finally one of the justifications to finally shut it down was > that usage was minimal.I think GPS offers more global coverage. IIRC, there are dark spots where no GRI effectively covers the area. And, you'd probably want to compensate for propagation delays over water vs. over land. But, hell, a LORAN receiver was a few *KB* of code (on an 8b CPU). You could store a detailed map of the globe in the other hundred KB available in a cheap SoC! :-/> And it's far from clear that the current (US) GPS system is going to > maintain a full complement of satellites over the next 15 years, given > likely retirement rates (most of the active birds are operating well > beyond their design lifetimes already), and the rate of replacement > launches (the latter being impacted by numerous development delays and > funding issues). At least GLONASS is back online, and we may see > Galileo and Compass** online by 2020, so we'll have some redundancy > there if the application needs it. > > Sorry, this is a bit of a hobbyhorse for me...
Reply by ●October 9, 20132013-10-09
Hi Tim, On 10/8/2013 10:23 AM, Tim Wescott wrote:> I'm trying to think of a good example of where there may be a distinct > and valid tradeoff between the cost to develop some technology versus the > cost to deploy it.Assuming you mean: Approach A: Development cost $A1 Deployment cost $A2 vs. Approach B: Development cost $B1 Deployment cost $B2 and your point being that you may have erroneous costs for A2 & B2 in each of the above (e.g., perhaps assuming them to be equal?). The obvious example (IMO) would be "software updates" for desktop PC's. (or, any other product for that matter). I.e., you estimate the cost of supporting an update to be very low (you release a new piece of code that knows how to install itself, stop any competing services, start new services, restart computer, etc.). It's "inexpensive" to distribute those updates (let users download them, etc.). This drives A1 down and lets you con yourself into thinking A2 is also low. In reality, A2 has lots of user-borne costs that, eventually, appear in the user's TCO -- effectively making your A1 *look* much higher (even though the user didn't give YOU the monies directly, he still bore the costs!) The alternative approach is to remove the user from the update process. E.g., "auto updates". This increases your B1 and B2, slightly. But, offsets (hopefully) the "hidden" costs that were associated with A2 in the original implementation. Of course, the real solution is C -- don't *need* so many updates! (how many buffer overrun errors do you need to stumble upon before you realize they *all* need to be rechecked???!) You could also spin this other ways drawing on the ACTUAL "user experience" with auto updates, etc. Sorry, I could probably come up with a better example but I've got "workstations on the brain", lately :<
