Meat of your comment to me is this phrase, “he had this insight about the balance between when to use hardware and when to use software that I think is somewhat lacking today” - would you attempt to clarify what you’re expressing he would have said about balancing the design of how software & hardware work together? Thanks.
Here is what I learned back then. What we were working on was an automated system to monitor data circuits, which back then were basically modems connected to a dedicated audio circuit. They called it a private line data circuit.
The problem back then of course was that you essentially needed a way to sample the audio modem circuit and do analysis of it. We had written some code on a Symbolics computer that could do the analysis (that was the old timey LISP type AI computer).
The trick was how to get the samples without a person having to jack in and record it or whatever. Today this seems trivial but it was more complicated back then. We brainstormed on it (he had a sharp ear BTW). We ended up building a device that had some custom hardware on it that then interfaced the ADC over DMA to a 68000 processor and could monitor multiple circuits etc. and fed that to the Symbolics which could predict all sorts of things.
Anyhow, it taught me how you could sort of combine the two to offload some stuff to HW but still keep the flexibility of SW.
I see a lot of similar types of trade offs today. Now of course we have FPGA's for hardware that can do a lot but you still need interface circuitry to the real world depending on the application. I have worked on a lot of projects where there is a tendency to always reach for software or vice versa.
What I think happens is you might have a company let's say company 'G' that is basically a software company and everyone they hire knows software really well. And they interview and hire more software people. Then if they were to let's say... buy a company that makes HW, perhaps phones, they have a difficult time. Or they try to build out a network and struggle.
Then maybe you have another company 'V' and they are good at building a network but they don't understand software so if they buy a software company it is difficult for them.
Then you have a company Apple that has always done both and they seem to make better choices.
I am sure a lot of you out there can think of similar examples.
This is just my observations based on my experiences. The more a team has a diverse set of experiences and background (HW, SW, Network) the better the chance of getting an optimal solution.
I think now it would be comparable to having good clue which workload should be server side vs which workload should be client side in web dev. Back end devs want to do all on back end and front end guys want to do all in front end. Then you get issues like API returning too much data that someone can abuse or hundreds of calls with ajax to setup something....
