On Wed, 14 Dec 2022 10:54:02 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 12/14/2022 8:48 AM, Joe Gwinn wrote:
>>>> Modern radars have lots of both, and the firmware is also very
>>>> complex. Many things are done in FPGAs for speed. Like signal
>>>> processing.
>>>>
>>>> In military radars, great availability is required, because mid-battle
>>>> repairs are basically impossible.
>>>
>>> That's true of other fields, as well. You can't stop an
>>> operation because some bit of kit shit the bed. And, many
>>> product lines consider the cost of down time to be next
>>> to astronomical (though no one *dies* as a consequence).
>>>
>>>> Yes, adding a completely new kind of target is expensive, but what
>>>> would the alternative be?
>>>
>>> My point was the relative costs of adding it in *software* vs. a
>>> *hardware* implementation ("recognizer").
>>
>> What is ever increasing is the complexity of what is to be done. How
>
>Exactly. The easy stuff has already been done.
>
>> this complexity is parceled out to software, firmware, and hardware
>> changes with the interplay between various evolving technologies. But
>> the overall complexity never decreases.
>
>Complexity increases largely because expectations of what *can*
>be done are ever increasing.

Definitely. One is driven by one's competitors.

>Garage doors used to be manually raised/lowered.
>Then, along came *openers* (why have they not been called "closers"?)
>Then, *remotes* so you could actuate from your vehicle (approaching/leaving).
>Then, load sensing so it could stop/reverse when encountering an obstacle.
>Then, "electric eyes" to inhibit closure when the path is blocked.
>
>I, now, use *cameras* to check the entirety of the door's path.
>An "electric eye" might detect something directly in it's "beam"
>and completely miss something that *straddles* it or rises above
>(like a kid's wagon or the front/rear end of your vehicle).
>And, there is no protection against the door *rising*! Imagine
>being on a ladder accessing an attic-space above the door and
>having someone (approaching on the street) actuating the door;
>it rises into the erected ladder!
>
>And, what if the obstacles are in the path of the *vehicle* but
>not the door, itself? Is the driver (or obstacles) alerted/protected
>in those cases?
>
>A decade ago, backup cameras, blindspot monitors, etc. were all
>"exotic" options for vehicles. Now, they're a matter of course.

Yep.

>>> My second product was a LORAN plotter. I don't think we had
>>> formally released the design to manufacturing before "Marketing"
>>> started asking for features (that they didn't think of in the
>>> product specification phase!). You can't just have the
>>> customer bring the unit back for an upgrade as it is likely
>>> fastened to the bridge on his vessel (so it doesn't get tossed
>>> about in a rough sea).
>>
>> Yeah. On one project many decades ago, one of my bigger contributions
>> was to get a requirements freeze imposed, giving time for design and
>> integration to settle and complete. The ~marketing folk had no idea
>> of the need for a freeze, and would never stop fiddling and tweaking,
>> especially as the deadline approached and their anxiety levels grew
>> exponentially.
>
>Yes. And sales/marketing people never want to risk losing a
>sale because The Competitor offered a feature that they didn't
>have. So, drag out the kitchen sink!
>
>I put together a proposal for a new product at a firm. I pitched
>it to upper management in a room full of engineers (to critique
>technical issues) and sales people (to critique it's marketability).
>
>One of the key features of my design was immediately called into
>question by the sales staff. I was eliminating a "use case"
>that needlessly complicated the design. "Oh, no! We've GOT to
>have that!!"
>
>What they hadn't considered was that I had analyzed ALL of
>the previous purchases to determine which features were actually
>*bought* whereas they were speaking out of fear (self preservation?).
>
>"You sold exactly ONE unit with that feature in the 15? years you'd
>offered the previous model..."
>
>Which was met with silence. And, the owner staring me down trying
>to sort out whether I should be in the "asset" or "liability"
>column. The CEO broke the silence by stating, "Yeah, and I bet
>i know exactly where that unit went!"
>
>In a *rational* environment, one would present the cost of
>developing (and producing) that optional capability and offset
>the *projected* sales revenues against it to make the design
>decision. But, if the option is something more than a
>differential stuffing issue where the additional parts have
>an easily quantified cost, who's going to invest the time to
>come up with detailed estimates of the development efforts
>of "path A" vs. "path B" -- in *most* companies?
>
>Instead, you rely on personal experience to make those decisions.
>
>[At the LORAN company, one salesperson made a big deal out of
>*needing* a specific feature in a product. Engineering eventually
>conceded to his requests. He *never* sold a unit with that
>feature. And, thereafter, was ignored in all product design
>meetings.]
>
>>> This is the bane of software-based products; they are seen as so
>>> easy to change that folks don't exhibit the same sort of discipline
>>> in coming up with wishlists that they would with a hardware design.
>>
>> Well, the issue is not "people" in general, its the leadership folk
>> who decide when to stop the fiddling and tweaking. Your average
>> engineer is not in charge of this.
>
>Right. But, many folks in decision making positions aren't
>capable of understanding the technical *or* marketing issues
>at stake. They have to rely on others with those abilities.
>*THEIR* role is to understand the personalities of those
>"others" to know when to listen to their advice and when to
>discount it.
>
>It's hard to predict how "late" a design could be as the result of
>a *specific* decision. OTOH, it's fairly obvious (after the fact)
>when a missing feature has cost you market share!
>
>>> [Can you imagine being asked to add a two way *radio* capability
>>> to your RADAR? "After all, it's already got a TRANSMITTER built in..."]
>>
>> Well, actually military radars have done that for decades, to be able
>> to talk to interceptor missiles in flight.
>>
>> .<https://en.wikipedia.org/wiki/Track-via-missile>
>
>But as a separate product. You're not using the actual maggie to
>send CW.
>
>>> "Agile" just turns that into a religion! <frown> (how the hell can
>>> you start a design if you don't know what you're designing? and,
>>> you expect it to *work*? bug-free??)
>>
>> Agile can work for making small changed to a large existing codebase.
>> But it's pretty much useless for starting from a clean sheet.
>
>Agile seems to cater to indecision. "I don't know what I want
>but I'll know what I *don't* want WHEN I SEE IT!" Who the hell
>would start building a house (car, boat, toaster, etc.) with
>the likely expectation that some number of iterations are going
>to NOT be accepted? No, the *builder* isn't learning much
>that he already didn't know; it's the indecisive client who
>is doing the learning (and stunned at the price to pay for it!)
>
>I've had great success with projects using "traditional" design
>methodologies. "Let's figure out what we *want*. Then, I can
>figure out what to put into recurring hardware costs and what
>to implement in software. And, develop a test metholodogy
>BEFORE the design is released to manufacturing."
>
>As a contractor/consultant, this is a REAL win as it makes
>the deliverables stand out in very clear terms. And, the
>conditions for sign-off very explicit: walk through the
>specification and verify every stated requirement.
>
>"Pay the man!"

Well, this thread also seems to be expanding without limit, well
exceeding my ambition, so I'll bail out now.

Joe Gwinn