"Moreover, J.D Power and Consumer Reports have Tesla at the bottom of their lists when it comes to reliability, reporting an average of 171 mechanical issues per 100 vehicles, 51 more than the average for other car manufacturers."

Every single aspect of the business operation is mismanaged. The banks and finance investment industries are surprisingly moronic in this regard. It's estimated the banking consortium (Morgan Stanley) that lent Musk $13.5B for the Twitter buy are already out $500M in a so-called mark-to-market loss.. They can't give the loan away for 60 cents on the dollar, even the high risk players don't want to touch it. And Musk is going back to them for even more money.

https://www.hotcars.com/real-truth-about-tesla-reliability/

On Sat, 10 Dec 2022 07:00:46 -0800 (PST), Fred Bloggs
<bloggs.fredbloggs.fred@gmail.com> wrote:

>"Moreover, J.D Power and Consumer Reports have Tesla at the bottom of their lists when it comes to reliability, reporting an average of 171 mechanical issues per 100 vehicles, 51 more than the average for other car manufacturers."
>
>Every single aspect of the business operation is mismanaged. The banks and finance investment industries are surprisingly moronic in this regard. It's estimated the banking consortium (Morgan Stanley) that lent Musk $13.5B for the Twitter buy are already out $500M in a so-called mark-to-market loss. They can't give the loan away for 60 cents on the dollar, even the high risk players don't want to touch it. And Musk is going back to them for even more money.
>
>https://www.hotcars.com/real-truth-about-tesla-reliability/

Tesla has sold over 3 million cars, over 80,000 in March. The fans
aren't chased away by concern over reliability.

PT Cruiser sold a lot of cars too.

On Saturday, December 10, 2022 at 10:43:41 AM UTC-5, John Larkin wrote:
> On Sat, 10 Dec 2022 07:00:46 -0800 (PST), Fred Bloggs
> <bloggs.fred...@gmail.com> wrote:
>
> >"Moreover, J.D Power and Consumer Reports have Tesla at the bottom of their lists when it comes to reliability, reporting an average of 171 mechanical issues per 100 vehicles, 51 more than the average for other car manufacturers."
> >
> >Every single aspect of the business operation is mismanaged. The banks and finance investment industries are surprisingly moronic in this regard. It's estimated the banking consortium (Morgan Stanley) that lent Musk $13.5B for the Twitter buy are already out $500M in a so-called mark-to-market loss. They can't give the loan away for 60 cents on the dollar, even the high risk players don't want to touch it. And Musk is going back to them for even more money.
> >
> >https://www.hotcars.com/real-truth-about-tesla-reliability/
> Tesla has sold over 3 million cars, over 80,000 in March. The fans
> aren't chased away by concern over reliability.
>
> PT Cruiser sold a lot of cars too.

Those people aren't doing their homework. They have choice. There are quite a few really great products from established automakers:

Meanwhile, in the United States, buyers can select between the BMW i4 eDrive 40, which has a starting price of $55,900, the 2023 Hyundai Ioniq 6 with a MSRP of $44,000, the 2023 Kia EV6 retailing at a MSRP of $41,400, the 2023 Polestar 2 with a MSRP of $48,400, or even more affordable options like the cute 2023 Nissan LEAF, which has a starting price of $28,040.

None of them pay their CEO $50 BILLION annually!

This Is Why Tesla's Piece Of The EV Pie Is Shrinking

https://www.hotcars.com/why-teslas-piece-of-the-ev-pie-is-shrinking/

On Saturday, December 10, 2022 at 9:09:59 AM UTC-8, Fred Bloggs wrote:
....
> None of them pay their CEO $50 BILLION annually!

To be fair, only once. He is likely getting -$10B this year.

On Sat, 10 Dec 2022 09:09:54 -0800 (PST), Fred Bloggs
<bloggs.fredbloggs.fred@gmail.com> wrote:

>On Saturday, December 10, 2022 at 10:43:41 AM UTC-5, John Larkin wrote:
>> On Sat, 10 Dec 2022 07:00:46 -0800 (PST), Fred Bloggs
>> <bloggs.fred...@gmail.com> wrote:
>>
>> >"Moreover, J.D Power and Consumer Reports have Tesla at the bottom of their lists when it comes to reliability, reporting an average of 171 mechanical issues per 100 vehicles, 51 more than the average for other car manufacturers."
>> >
>> >Every single aspect of the business operation is mismanaged. The banks and finance investment industries are surprisingly moronic in this regard. It's estimated the banking consortium (Morgan Stanley) that lent Musk $13.5B for the Twitter buy are already out $500M in a so-called mark-to-market loss. They can't give the loan away for 60 cents on the dollar, even the high risk players don't want to touch it. And Musk is going back to them for even more money.
>> >
>> >https://www.hotcars.com/real-truth-about-tesla-reliability/
>> Tesla has sold over 3 million cars, over 80,000 in March. The fans
>> aren't chased away by concern over reliability.
>>
>> PT Cruiser sold a lot of cars too.
>
>Those people aren't doing their homework. They have choice. There are quite a few really great products from established automakers:
>
>Meanwhile, in the United States, buyers can select between the BMW i4 eDrive 40, which has a starting price of $55,900, the 2023 Hyundai Ioniq 6 with a MSRP of $44,000, the 2023 Kia EV6 retailing at a MSRP of $41,400, the 2023 Polestar 2 with a MSRP of $48,400, or even more affordable options like the cute 2023 Nissan LEAF, which has a starting price of $28,040.
>
>None of them pay their CEO $50 BILLION annually!

Musk's salary from Tesla is $0.

On Saturday, December 10, 2022 at 10:29:45 AM UTC-8, John Larkin wrote:
> On Sat, 10 Dec 2022 09:09:54 -0800 (PST), Fred Bloggs
> <bloggs.fred...@gmail.com> wrote:
>
> >On Saturday, December 10, 2022 at 10:43:41 AM UTC-5, John Larkin wrote:
> >> On Sat, 10 Dec 2022 07:00:46 -0800 (PST), Fred Bloggs
> >> <bloggs.fred...@gmail.com> wrote:
> >>
> >> >"Moreover, J.D Power and Consumer Reports have Tesla at the bottom of their lists when it comes to reliability, reporting an average of 171 mechanical issues per 100 vehicles, 51 more than the average for other car manufacturers."
> >> >
> >> >Every single aspect of the business operation is mismanaged. The banks and finance investment industries are surprisingly moronic in this regard.. It's estimated the banking consortium (Morgan Stanley) that lent Musk $13..5B for the Twitter buy are already out $500M in a so-called mark-to-market loss. They can't give the loan away for 60 cents on the dollar, even the high risk players don't want to touch it. And Musk is going back to them for even more money.
> >> >
> >> >https://www.hotcars.com/real-truth-about-tesla-reliability/
> >> Tesla has sold over 3 million cars, over 80,000 in March. The fans
> >> aren't chased away by concern over reliability.
> >>
> >> PT Cruiser sold a lot of cars too.
> >
> >Those people aren't doing their homework. They have choice. There are quite a few really great products from established automakers:
> >
> >Meanwhile, in the United States, buyers can select between the BMW i4 eDrive 40, which has a starting price of $55,900, the 2023 Hyundai Ioniq 6 with a MSRP of $44,000, the 2023 Kia EV6 retailing at a MSRP of $41,400, the 2023 Polestar 2 with a MSRP of $48,400, or even more affordable options like the cute 2023 Nissan LEAF, which has a starting price of $28,040.
> >
> >None of them pay their CEO $50 BILLION annually!
> Musk's salary from Tesla is $0.

The CEO's salary is the LAST thing I want to know when buying a new car (which I have done recently). I am more interested in their reliability record.. I owned an F-250 Super Duty for 10 years that was nearly flawless, so guess what I replaced it with? Tesla, on the other hand, has MANY horror stories about flaws and the problems getting them repaired, which I have posted about.

On Sun, 11 Dec 2022 23:56:22 -0800 (PST), Flyguy
<soar2morrow@yahoo.com> wrote:

>On Saturday, December 10, 2022 at 10:29:45 AM UTC-8, John Larkin wrote:
>> On Sat, 10 Dec 2022 09:09:54 -0800 (PST), Fred Bloggs
>> <bloggs.fred...@gmail.com> wrote:
>>
>> >On Saturday, December 10, 2022 at 10:43:41 AM UTC-5, John Larkin wrote:
>> >> On Sat, 10 Dec 2022 07:00:46 -0800 (PST), Fred Bloggs
>> >> <bloggs.fred...@gmail.com> wrote:
>> >>
>> >> >"Moreover, J.D Power and Consumer Reports have Tesla at the bottom of their lists when it comes to reliability, reporting an average of 171 mechanical issues per 100 vehicles, 51 more than the average for other car manufacturers."
>> >> >
>> >> >Every single aspect of the business operation is mismanaged. The banks and finance investment industries are surprisingly moronic in this regard. It's estimated the banking consortium (Morgan Stanley) that lent Musk $13.5B for the Twitter buy are already out $500M in a so-called mark-to-market loss. They can't give the loan away for 60 cents on the dollar, even the high risk players don't want to touch it. And Musk is going back to them for even more money.
>> >> >
>> >> >https://www.hotcars.com/real-truth-about-tesla-reliability/
>> >> Tesla has sold over 3 million cars, over 80,000 in March. The fans
>> >> aren't chased away by concern over reliability.
>> >>
>> >> PT Cruiser sold a lot of cars too.
>> >
>> >Those people aren't doing their homework. They have choice. There are quite a few really great products from established automakers:
>> >
>> >Meanwhile, in the United States, buyers can select between the BMW i4 eDrive 40, which has a starting price of $55,900, the 2023 Hyundai Ioniq 6 with a MSRP of $44,000, the 2023 Kia EV6 retailing at a MSRP of $41,400, the 2023 Polestar 2 with a MSRP of $48,400, or even more affordable options like the cute 2023 Nissan LEAF, which has a starting price of $28,040.
>> >
>> >None of them pay their CEO $50 BILLION annually!
>> Musk's salary from Tesla is $0.
>
>The CEO's salary is the LAST thing I want to know when buying a new car (which I have done recently). I am more interested in their reliability record. I owned an F-250 Super Duty for 10 years that was nearly flawless, so guess what I replaced it with? Tesla, on the other hand, has MANY horror stories about flaws and the problems getting them repaired, which I have posted about.

Teslas are always online to the factory, sort of a subscription
software service. There could be long-term support and reliability
issues there.

On 2022-12-12 16:25, John Larkin wrote:
>
> Teslas are always online to the factory, sort of a subscription
> software service. There could be long-term support and reliability
> issues there.
>

Isn't that true for most cars nowadays? Modern cars are
computers with wheels rather than the reverse. They need
to be updated almost as often as a Windows box, and the
software crashes almost as often too.

Jeroen Belleman

On Monday, December 12, 2022 at 11:26:01 AM UTC-4, John Larkin wrote:
> On Sun, 11 Dec 2022 23:56:22 -0800 (PST), Flyguy
> <soar2...@yahoo.com> wrote:
>
> >On Saturday, December 10, 2022 at 10:29:45 AM UTC-8, John Larkin wrote:
> >> On Sat, 10 Dec 2022 09:09:54 -0800 (PST), Fred Bloggs
> >> <bloggs.fred...@gmail.com> wrote:
> >>
> >> >On Saturday, December 10, 2022 at 10:43:41 AM UTC-5, John Larkin wrote:
> >> >> On Sat, 10 Dec 2022 07:00:46 -0800 (PST), Fred Bloggs
> >> >> <bloggs.fred...@gmail.com> wrote:
> >> >>
> >> >> >"Moreover, J.D Power and Consumer Reports have Tesla at the bottom of their lists when it comes to reliability, reporting an average of 171 mechanical issues per 100 vehicles, 51 more than the average for other car manufacturers."
> >> >> >
> >> >> >Every single aspect of the business operation is mismanaged. The banks and finance investment industries are surprisingly moronic in this regard. It's estimated the banking consortium (Morgan Stanley) that lent Musk $13.5B for the Twitter buy are already out $500M in a so-called mark-to-market loss. They can't give the loan away for 60 cents on the dollar, even the high risk players don't want to touch it. And Musk is going back to them for even more money.
> >> >> >
> >> >> >https://www.hotcars.com/real-truth-about-tesla-reliability/
> >> >> Tesla has sold over 3 million cars, over 80,000 in March. The fans
> >> >> aren't chased away by concern over reliability.
> >> >>
> >> >> PT Cruiser sold a lot of cars too.
> >> >
> >> >Those people aren't doing their homework. They have choice. There are quite a few really great products from established automakers:
> >> >
> >> >Meanwhile, in the United States, buyers can select between the BMW i4 eDrive 40, which has a starting price of $55,900, the 2023 Hyundai Ioniq 6 with a MSRP of $44,000, the 2023 Kia EV6 retailing at a MSRP of $41,400, the 2023 Polestar 2 with a MSRP of $48,400, or even more affordable options like the cute 2023 Nissan LEAF, which has a starting price of $28,040.
> >> >
> >> >None of them pay their CEO $50 BILLION annually!
> >> Musk's salary from Tesla is $0.
> >
> >The CEO's salary is the LAST thing I want to know when buying a new car (which I have done recently). I am more interested in their reliability record. I owned an F-250 Super Duty for 10 years that was nearly flawless, so guess what I replaced it with? Tesla, on the other hand, has MANY horror stories about flaws and the problems getting them repaired, which I have posted about.
> Teslas are always online to the factory, sort of a subscription
> software service. There could be long-term support and reliability
> issues there.

Really? What part of a car does not represent reliability issues?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On Mon, 12 Dec 2022 17:04:20 +0100, Jeroen Belleman
<jeroen@nospam.please> wrote:

>On 2022-12-12 16:25, John Larkin wrote:
>>
>> Teslas are always online to the factory, sort of a subscription
>> software service. There could be long-term support and reliability
>> issues there.
>>
>
>Isn't that true for most cars nowadays? Modern cars are
>computers with wheels rather than the reverse. They need
>to be updated almost as often as a Windows box, and the
>software crashes almost as often too.
>
>Jeroen Belleman

I can probably rebuild my A3 for decades.

On Monday, December 12, 2022 at 12:33:02 PM UTC-4, John Larkin wrote:
> On Mon, 12 Dec 2022 17:04:20 +0100, Jeroen Belleman
> <jer...@nospam.please> wrote:
>
> >On 2022-12-12 16:25, John Larkin wrote:
> >>
> >> Teslas are always online to the factory, sort of a subscription
> >> software service. There could be long-term support and reliability
> >> issues there.
> >>
> >
> >Isn't that true for most cars nowadays? Modern cars are
> >computers with wheels rather than the reverse. They need
> >to be updated almost as often as a Windows box, and the
> >software crashes almost as often too.
> >
> >Jeroen Belleman
> I can probably rebuild my A3 for decades.

That's true. It will be around two decades for ICE to become largely extinct.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

On Saturday, 10 December 2022 at 09:09:59 UTC-8, Fred Bloggs wrote:
> On Saturday, December 10, 2022 at 10:43:41 AM UTC-5, John Larkin wrote:
> > On Sat, 10 Dec 2022 07:00:46 -0800 (PST), Fred Bloggs
> > <bloggs.fred...@gmail.com> wrote:
> >
> > >"Moreover, J.D Power and Consumer Reports have Tesla at the bottom of their lists when it comes to reliability, reporting an average of 171 mechanical issues per 100 vehicles, 51 more than the average for other car manufacturers."
> > >
> > >Every single aspect of the business operation is mismanaged. The banks and finance investment industries are surprisingly moronic in this regard. It's estimated the banking consortium (Morgan Stanley) that lent Musk $13.5B for the Twitter buy are already out $500M in a so-called mark-to-market loss. They can't give the loan away for 60 cents on the dollar, even the high risk players don't want to touch it. And Musk is going back to them for even more money.
> > >
> > >https://www.hotcars.com/real-truth-about-tesla-reliability/
> > Tesla has sold over 3 million cars, over 80,000 in March. The fans
> > aren't chased away by concern over reliability.
> >
> > PT Cruiser sold a lot of cars too.
> Those people aren't doing their homework. They have choice. There are quite a few really great products from established automakers:
>
> Meanwhile, in the United States, buyers can select between the BMW i4 eDrive 40, which has a starting price of $55,900, the 2023 Hyundai Ioniq 6 with a MSRP of $44,000, the 2023 Kia EV6 retailing at a MSRP of $41,400, the 2023 Polestar 2 with a MSRP of $48,400, or even more affordable options like the cute 2023 Nissan LEAF, which has a starting price of $28,040.
>
> None of them pay their CEO $50 BILLION annually!
>
> This Is Why Tesla's Piece Of The EV Pie Is Shrinking
>
> https://www.hotcars.com/why-teslas-piece-of-the-ev-pie-is-shrinking/

Tesla can sell every car they make, and are making them as fast as they can and accelerating having opened many new factories over the last couple of years.

The reason they are losing market share is that many other manufacturers are coming into the marketplace being attracted by Tesla's success. Most of the TVs are difficult to get with very long lead times as demand is so high.

kw

On Monday, December 12, 2022 at 7:59:31 PM UTC-4, ke...@kjwdesigns.com wrote:
> On Saturday, 10 December 2022 at 09:09:59 UTC-8, Fred Bloggs wrote:
> > On Saturday, December 10, 2022 at 10:43:41 AM UTC-5, John Larkin wrote:
> > > On Sat, 10 Dec 2022 07:00:46 -0800 (PST), Fred Bloggs
> > > <bloggs.fred...@gmail.com> wrote:
> > >
> > > >"Moreover, J.D Power and Consumer Reports have Tesla at the bottom of their lists when it comes to reliability, reporting an average of 171 mechanical issues per 100 vehicles, 51 more than the average for other car manufacturers."
> > > >
> > > >Every single aspect of the business operation is mismanaged. The banks and finance investment industries are surprisingly moronic in this regard. It's estimated the banking consortium (Morgan Stanley) that lent Musk $13.5B for the Twitter buy are already out $500M in a so-called mark-to-market loss. They can't give the loan away for 60 cents on the dollar, even the high risk players don't want to touch it. And Musk is going back to them for even more money.
> > > >
> > > >https://www.hotcars.com/real-truth-about-tesla-reliability/
> > > Tesla has sold over 3 million cars, over 80,000 in March. The fans
> > > aren't chased away by concern over reliability.
> > >
> > > PT Cruiser sold a lot of cars too.
> > Those people aren't doing their homework. They have choice. There are quite a few really great products from established automakers:
> >
> > Meanwhile, in the United States, buyers can select between the BMW i4 eDrive 40, which has a starting price of $55,900, the 2023 Hyundai Ioniq 6 with a MSRP of $44,000, the 2023 Kia EV6 retailing at a MSRP of $41,400, the 2023 Polestar 2 with a MSRP of $48,400, or even more affordable options like the cute 2023 Nissan LEAF, which has a starting price of $28,040.
> >
> > None of them pay their CEO $50 BILLION annually!
> >
> > This Is Why Tesla's Piece Of The EV Pie Is Shrinking
> >
> > https://www.hotcars.com/why-teslas-piece-of-the-ev-pie-is-shrinking/
> Tesla can sell every car they make, and are making them as fast as they can and accelerating having opened many new factories over the last couple of years.
>
> The reason they are losing market share is that many other manufacturers are coming into the marketplace being attracted by Tesla's success. Most of the TVs are difficult to get with very long lead times as demand is so high.

Some people don't understand when you dominate a market because there are so few competitors that take the market seriously, that will change as the competitors wise up and gear up.

Losing market share is not the same thing as shrinking.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

On 2022-12-12 17:32, John Larkin wrote:
> On Mon, 12 Dec 2022 17:04:20 +0100, Jeroen Belleman
> <jeroen@nospam.please> wrote:
>
>> On 2022-12-12 16:25, John Larkin wrote:
>>>
>>> Teslas are always online to the factory, sort of a subscription
>>> software service. There could be long-term support and reliability
>>> issues there.
>>>
>>
>> Isn't that true for most cars nowadays? Modern cars are
>> computers with wheels rather than the reverse. They need
>> to be updated almost as often as a Windows box, and the
>> software crashes almost as often too.
>>
>> Jeroen Belleman
>
> I can probably rebuild my A3 for decades.
>

I drive an A7. It's buggy. I'm not happy.

Jeroen Belleman

On Tue, 13 Dec 2022 10:02:50 +0100, Jeroen Belleman
<jeroen@nospam.please> wrote:

>On 2022-12-12 17:32, John Larkin wrote:
>> On Mon, 12 Dec 2022 17:04:20 +0100, Jeroen Belleman
>> <jeroen@nospam.please> wrote:
>>
>>> On 2022-12-12 16:25, John Larkin wrote:
>>>>
>>>> Teslas are always online to the factory, sort of a subscription
>>>> software service. There could be long-term support and reliability
>>>> issues there.
>>>>
>>>
>>> Isn't that true for most cars nowadays? Modern cars are
>>> computers with wheels rather than the reverse. They need
>>> to be updated almost as often as a Windows box, and the
>>> software crashes almost as often too.
>>>
>>> Jeroen Belleman
>>
>> I can probably rebuild my A3 for decades.
>>
>
>I drive an A7. It's buggy. I'm not happy.
>
>Jeroen Belleman

Mine's a 2008, 3.2l V6 non-turbo. It's mechanically wonderful and the
software sucks, but I bet it doesn't suck as much as later models.

The idea of a Tesla with a giant touch screen and continuously updated
software fills me with horror.

The trend in software is never finished, never right. You can always
fix it tomorrow if enough people complain.

On Tue, 13 Dec 2022 07:55:29 -0800, John Larkin
<jlarkin@highlandSNIPMEtechnology.com> wrote:

>On Tue, 13 Dec 2022 10:02:50 +0100, Jeroen Belleman
><jeroen@nospam.please> wrote:
>
>>On 2022-12-12 17:32, John Larkin wrote:
>>> On Mon, 12 Dec 2022 17:04:20 +0100, Jeroen Belleman
>>> <jeroen@nospam.please> wrote:
>>>
>>>> On 2022-12-12 16:25, John Larkin wrote:
>>>>>
>>>>> Teslas are always online to the factory, sort of a subscription
>>>>> software service. There could be long-term support and reliability
>>>>> issues there.
>>>>>
>>>>
>>>> Isn't that true for most cars nowadays? Modern cars are
>>>> computers with wheels rather than the reverse. They need
>>>> to be updated almost as often as a Windows box, and the
>>>> software crashes almost as often too.
>>>>
>>>> Jeroen Belleman
>>>
>>> I can probably rebuild my A3 for decades.
>>>
>>
>>I drive an A7. It's buggy. I'm not happy.
>>
>>Jeroen Belleman
>
>Mine's a 2008, 3.2l V6 non-turbo. It's mechanically wonderful and the
>software sucks, but I bet it doesn't suck as much as later models.
>
>The idea of a Tesla with a giant touch screen and continuously updated
>software fills me with horror.
>
>The trend in software is never finished, never right. You can always
>fix it tomorrow if enough people complain.

True enough, but actually is not the real problem.

Recall the days when Japanese cars came to America. The Japanese cars
were far more reliable than American cars (which were terrible) and
European cars (far better, except for British cars).

The US and European cars started to improve. The pecking order is
still preserved, but the Japanese are still ahead.

So, what's going on? The way to make a reliable car is to stand up a
permanent quality organization with teeth. Find out what is failing,
and insist that it be redesigned. Do this before first sales, so the
model starts out pretty good, and continue redesigning the problem
children as they surface. This improved subsequent models, because
the supply of problem children is steadily depleted, eventually
approaching a steady-state background level. Which level is a choice,
not a property of the universe.

I saw much the same happen in fielded military radar systems. These
were developed long before modern software engineering emerged,
claiming that without modern software engineering (and its endless
succession of development processes), it would be impossible to make
reliable software. But those fielded systems only rarely suffered a
software problem. Why? Because the military commands paid the radar
system developer to keep on fixing bugs until there were no more.
Until the next capability upgrade, which restarted the process.

So, if one wants reliability, one can insist on it, but must also pay
for it.

Joe Gwinn

On 12/13/2022 10:59 AM, Joe Gwinn wrote:
> I saw much the same happen in fielded military radar systems. These
> were developed long before modern software engineering emerged,
> claiming that without modern software engineering (and its endless
> succession of development processes), it would be impossible to make
> reliable software. But those fielded systems only rarely suffered a
> software problem. Why? Because the military commands paid the radar
> system developer to keep on fixing bugs until there were no more.
> Until the next capability upgrade, which restarted the process.
>
> So, if one wants reliability, one can insist on it, but must also pay
> for it.

Of course. One *expects* more (functionality) of a software
implementation than a pure hardware one.

Imagine the *recurring* (and development) costs of an all-hardware
radar system that can identify the aircraft and ordinance it "sees".

Then, imagine the cost of adding support for a new type of target!

On Tue, 13 Dec 2022 11:47:54 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 12/13/2022 10:59 AM, Joe Gwinn wrote:
>> I saw much the same happen in fielded military radar systems. These
>> were developed long before modern software engineering emerged,
>> claiming that without modern software engineering (and its endless
>> succession of development processes), it would be impossible to make
>> reliable software. But those fielded systems only rarely suffered a
>> software problem. Why? Because the military commands paid the radar
>> system developer to keep on fixing bugs until there were no more.
>> Until the next capability upgrade, which restarted the process.
>>
>> So, if one wants reliability, one can insist on it, but must also pay
>> for it.
>
>Of course. One *expects* more (functionality) of a software
>implementation than a pure hardware one.
>
>Imagine the *recurring* (and development) costs of an all-hardware
>radar system that can identify the aircraft and ordinance it "sees".
>
>Then, imagine the cost of adding support for a new type of target!

When I started, radars had little software. Typically, everything
from antenna to target echo detection was done in hardware (including
signal processing), and the resulting detection stream was fed into a
very large computer (for that day) which formed the tracks et al.

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.

Yes, adding a completely new kind of target is expensive, but what
would the alternative be?

Joe Gwinn

On 12/13/2022 4:55 PM, Joe Gwinn wrote:
> On Tue, 13 Dec 2022 11:47:54 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> On 12/13/2022 10:59 AM, Joe Gwinn wrote:
>>> I saw much the same happen in fielded military radar systems. These
>>> were developed long before modern software engineering emerged,
>>> claiming that without modern software engineering (and its endless
>>> succession of development processes), it would be impossible to make
>>> reliable software. But those fielded systems only rarely suffered a
>>> software problem. Why? Because the military commands paid the radar
>>> system developer to keep on fixing bugs until there were no more.
>>> Until the next capability upgrade, which restarted the process.
>>>
>>> So, if one wants reliability, one can insist on it, but must also pay
>>> for it.
>>
>> Of course. One *expects* more (functionality) of a software
>> implementation than a pure hardware one.
>>
>> Imagine the *recurring* (and development) costs of an all-hardware
>> radar system that can identify the aircraft and ordinance it "sees".
>>
>> Then, imagine the cost of adding support for a new type of target!
>
> When I started, radars had little software. Typically, everything
> from antenna to target echo detection was done in hardware (including
> signal processing), and the resulting detection stream was fed into a
> very large computer (for that day) which formed the tracks et al.

Yup. I worked for a firm that made radars for boats. The fact
that we digitized the return (to play it out) was considered
"leading edge".

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

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

One was a remote "button" (contact closure) that would allow
the "operator" to cause an "X" to be drawn on the plot at the
current position. (think of a lobsterman dropping a pot over
the side and wanting a record of its location so he could later
retrieve it). Had the plotter been implemented in hardware
(likely impractical as the time-difference to lat-lon conversion
is pretty messy), this would have required some significant
modification to:
- figure out *when* the "pen" was AT the current position
(because there is an inherent lag between the LORAN
receiver, the TD-Lλ conversion and the motor drivers)
- lift the pen
- move off current position to the end of one "arm" of the X
- drop pen
- move diagonally to other end of that arm
- lift pen
- move across to end of other arm
- drop pen
- move diagonally to other end of THAT arm
- lift pen
- return pen to "current position" at the time this was started
- catch up to present current position (following whatever
track the boat had actually taken -- not just a straight line)

The software solution required a small (postage stamp) signal conditioning
board (to ensure the remote "button" didn't act as a nasty antenna) and
a few lines of code. Implemented and tested in a matter of hours
(we could fab 2 layer boards in-house)

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.

[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..."]

"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??)

John Larkin wrote:
> On Tue, 13 Dec 2022 10:02:50 +0100, Jeroen Belleman
> <jeroen@nospam.please> wrote:
>
>> On 2022-12-12 17:32, John Larkin wrote:
>>> On Mon, 12 Dec 2022 17:04:20 +0100, Jeroen Belleman
>>> <jeroen@nospam.please> wrote:
>>>
>>>> On 2022-12-12 16:25, John Larkin wrote:
>>>>>
>>>>> Teslas are always online to the factory, sort of a subscription
>>>>> software service. There could be long-term support and reliability
>>>>> issues there.
>>>>>
>>>>
>>>> Isn't that true for most cars nowadays? Modern cars are
>>>> computers with wheels rather than the reverse. They need
>>>> to be updated almost as often as a Windows box, and the
>>>> software crashes almost as often too.
>>>>
>>>> Jeroen Belleman
>>>
>>> I can probably rebuild my A3 for decades.
>>>
>>
>> I drive an A7. It's buggy. I'm not happy.
>>
>> Jeroen Belleman
>
> Mine's a 2008, 3.2l V6 non-turbo. It's mechanically wonderful and the
> software sucks, but I bet it doesn't suck as much as later models.
>
> The idea of a Tesla with a giant touch screen and continuously updated
> software fills me with horror.
>

It's preposterous. And I say that as a primarily software
person.

> The trend in software is never finished, never right. You can always
> fix it tomorrow if enough people complain.
>

There are great ways to construct software to reduce the margin of
error rapidly. These grew up around telecoms. Basically,
do what FPGA people do.

Nobody is interested. You really do have the problem
of what to do with staff once they're done and the "lurn
to code" method of economic engagement is too loud to
overcome.

"I know he can get the job, but can he do the job.
I know he can get the job, but can he do the job. " :8
- Mr Hatari, "Joe Vs. the Volcano."

( :8 means "repeat infinitely" )

--
Les Cargill

On 12/13/2022 7:22 PM, Les Cargill wrote:
> It's preposterous. And I say that as a primarily software
> person.

This is no different than all the web-based services and
"subscription" services that have been replacing "licensed"
seats.

The selling point is that you can fix/update the software
much easier than having to push updates to the end user.
But, the flip side is the user never knows what he is using
from one day to the next.

Can you even find a "version number" on a web-based service's
site? If Digikey errs, how do you report the error?

"I was using the version you had in place at 5:37PM on 11 Dec
when I observed the problem"

"Well, we can't reproduce it..."

"Are you using the 5:37PM 11 Dec version in your attempts?"

"No, it's now 8:14AM Dec 13. We no longer have that available
on our server..."

I.e., why bother reporting a problem if there's no way to
troubleshoot it?

Or, products with lifespans too short to remain "current"
long enough to warrant an upgrade! (How many upgrades in
your smart TV?)

> There are great ways to construct software to reduce the margin of
> error rapidly. These grew up around telecoms. Basically,
> do what FPGA people do.

The number one prerequisite is WANTING to produce a quality
product. And, knowing exactly what that product is intended to be.

> Nobody is interested. You really do have the problem
> of what to do with staff once they're done and the "lurn
> to code" method of economic engagement is too loud to
> overcome.

It's the mentality that leads to fast food restaurants putting
*pictures* of the menu items on the keys of the cash register
instead of requiring employees to be able to type in a numeric
value.

Or, giving you a handful of change that the *machine* dispensed
without even knowing if it is marginally correct.

The trend in all businesses is to lower the cost of the
providers -- nurses doing the work of doctors, progrmmers
doing the work of engineers/system designers, etc.

> "I know he can get the job, but can he do the job.
> I know he can get the job, but can he do the job. "  :8
> - Mr Hatari, "Joe Vs. the Volcano."
>
> ( :8 means "repeat infinitely" )

On Tue, 13 Dec 2022 17:19:38 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 12/13/2022 4:55 PM, Joe Gwinn wrote:
>> On Tue, 13 Dec 2022 11:47:54 -0700, Don Y
>> <blockedofcourse@foo.invalid> wrote:
>>
>>> On 12/13/2022 10:59 AM, Joe Gwinn wrote:
>>>> I saw much the same happen in fielded military radar systems. These
>>>> were developed long before modern software engineering emerged,
>>>> claiming that without modern software engineering (and its endless
>>>> succession of development processes), it would be impossible to make
>>>> reliable software. But those fielded systems only rarely suffered a
>>>> software problem. Why? Because the military commands paid the radar
>>>> system developer to keep on fixing bugs until there were no more.
>>>> Until the next capability upgrade, which restarted the process.
>>>>
>>>> So, if one wants reliability, one can insist on it, but must also pay
>>>> for it.
>>>
>>> Of course. One *expects* more (functionality) of a software
>>> implementation than a pure hardware one.
>>>
>>> Imagine the *recurring* (and development) costs of an all-hardware
>>> radar system that can identify the aircraft and ordinance it "sees".
>>>
>>> Then, imagine the cost of adding support for a new type of target!
>>
>> When I started, radars had little software. Typically, everything
>> from antenna to target echo detection was done in hardware (including
>> signal processing), and the resulting detection stream was fed into a
>> very large computer (for that day) which formed the tracks et al.
>
>Yup. I worked for a firm that made radars for boats. The fact
>that we digitized the return (to play it out) was considered
>"leading edge".
>
>> 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
this complexity is parceled out to software, firmware, and hardware
changes with the interplay between various evolving technologies. But
the overall complexity never decreases.

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

>One was a remote "button" (contact closure) that would allow
>the "operator" to cause an "X" to be drawn on the plot at the
>current position. (think of a lobsterman dropping a pot over
>the side and wanting a record of its location so he could later
>retrieve it). Had the plotter been implemented in hardware
>(likely impractical as the time-difference to lat-lon conversion
>is pretty messy), this would have required some significant
>modification to:
>- figure out *when* the "pen" was AT the current position
> (because there is an inherent lag between the LORAN
> receiver, the TD-L? conversion and the motor drivers)
>- lift the pen
>- move off current position to the end of one "arm" of the X
>- drop pen
>- move diagonally to other end of that arm
>- lift pen
>- move across to end of other arm
>- drop pen
>- move diagonally to other end of THAT arm
>- lift pen
>- return pen to "current position" at the time this was started
>- catch up to present current position (following whatever
> track the boat had actually taken -- not just a straight line)
>
>The software solution required a small (postage stamp) signal conditioning
>board (to ensure the remote "button" didn't act as a nasty antenna) and
>a few lines of code. Implemented and tested in a matter of hours
>(we could fab 2 layer boards in-house)

Technology not quite ready for this feature.

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

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

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

Joe Gwinn

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.

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.

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

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.

On 12/14/2022 2:32 PM, Joe Gwinn wrote:
>>> 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.

When you're the sole/leader in a market, you're most vulnerable
because you don't really know what the pricing structure *should* be
(and likely WILL, eventually, be!) in a more competitive environment.
Similarly, for the feature-set that customers *really* want (vs. what
you -- or some daft engineer -- THINK they want).

[Returning to the hardware/software issue...]

Too often, software pushes out incremental changes just to "be seen
as proactive". But, they are often just "can do's" instead of "should
do's". And, if bug-fixes mixed with feature-additions, the value
of the fixes is diminished.

IME, most customers/users are unimpressed with incremental changes
to a product. Offer them something substantive that they couldn't
get/approximate if you want to pique their interest.