As I've become more advanced in my career I've grown more frustrated with search engines for the same problems you described in your write up. This is a fantastic solution and such a refreshing way to use LLMs. I hope this project goes far!
I disagree with the examples in the second idea. The "bad" example is easier to understand and maintain at a glance in my opinion. Looking at the RegisterUser method, I can immediately see the steps it takes to register a user, whereas the "good" example I have to think about it a bit more. Of course, this is a simple example so not much thinking needs to be done, but in a more realistic application I think this would hold much more truth. In projects I've worked on I've seen methods get incredibly bloated due to this. I certainly do agree that "splitting things up for the sake of splitting them up" can be bad practice, I'm just not sure this is the best example to demonstrate that.
I agree. The main function of a component should describe what it does, similar to describing the algorithm in natural language. I have been following this pattern with success. It is much easier to understand things at a glance.
I've been a (somewhat successful) advocate of similar approaches at the automakers I've worked for, but it's not as simple as the article makes it sound. Individual components in each "zone" can have different reliability requirements, for example. They also might be produced by different suppliers, or only be present on certain models / trims.
Rivian is able to do this because they're taking advantage of modern heterogenous processors and they haven't made the mistake of outsourcing almost all of their software capabilities to tier 1,2,3 suppliers. Legacy OEMs find it much more difficult to adopt, especially once the institutional inertia takes over.
See gregmac's comment, it changes the failure modes and makes what could be isolated subsystem failures larger regional failures. However, components are also becoming much more reliable so this is an engineering tradeoff. Cases can be made in both directions.
EDIT: That's not the only tradeoff, but it is a key one.
Replacing word ECU with micro-controller makes number seem less insane. Okay, PCs are having less and less components. But one might ask why do so many components have any logic at all? We got extremely insanely powerful central CPUs with loads of memory and storage space. So why not just do absolutely everything there?
Remove any logic and computing from screens, keyboards, mice, SSDs, HDDs, off load everything from network chips and sounds chips. Just move all of it to CPU?
I think you'd want at least some "dumb" logic moved to the periphery, otherwise everything has to be conected directly to the CPU and you would still end up with tons of wiring. Also, some functions done in the periphery are ideal candidates for parallelization, such as the keyboard scanning the key matrix for pressed keys.
Seems like modularization is going to be beneficial pretty much anytime you can define an interface you think is going to be somewhat stable.
I wonder to what extent Rivian has removed intermediate controllers here, where they used them in the first place to get things done on a tighter timeline.
The value proposition of CAN bus is that peripherals can be scattered around connected by two data lines and a power wire. Dumb peripherals need more wiring.
Can is a great idea... But in practice the hardware to connect to the bus is ~10 cents, whereas the cheapest microcontrollers are ~1 cent. That means if you want thousands of connections for every peripheral, the costs of CAN transceivers really start to add up.
They are deviating from that already, aren't they? If they use one ECU per zone, then the peripherals in that zone can't be connected via CAN bus, otherwise they would need their own controller.
My mom put a deck of cards in my hand before I could walk, so i ended up being the one to teach all my friends in school. It takes a while to get it down
