The Overlooked Engineering Reality of the LiDAR Debate One of the least discussed aspects of the LiDAR debate is the actual engineering process behind it. People who haven’t been deep in the weeds of complex systems tend to wave it off: “Just throw on LiDAR. Problem solved. System safer.” That’s nowhere close to any engineering reality I’ve ever seen. Not once. Back in college, I took a robotics course as part of my computer science degree. On day one, the professor walked to the chalkboard and wrote four large letters: KISS (Keep It Simple, Stupid.) He explained that every engineer learns this lesson—either the hard way or the easy (smart) way. Then he gave us an assignment that threw us right into a classic KISS problem (which I detail below*). Anyone paying attention will recognize that KISS is embedded deep in Elon Musk’s five-step process**: “Delete, delete, delete.”, “Make the requirements less dumb.”, “The best part is no part.” ..all KISS principles. Adding LiDAR to a self-driving system violates KISS at nearly every level. It introduces massive complexity—not just in engineering, but in testing, in systems integration, and across the organizational structure. Let me explain. Sensor Conflict: Where’s Ground Truth? When two sensors disagree, which one is right? How big is that object? How far away is it? Is it moving? In which direction, and at what speed? Now add weather. Fog, rain, snow. Good luck getting reliable output from LiDAR in changing conditions—like when it's clear one second and raining the next. LiDAR emits light, and light scatters in moisture. Are we deprioritizing LiDAR mid-drive? Dynamically adjusting sensor weights? These aren’t hypotheticals— they’re engineering realities. Fusion Hell: Early or Late? You now face a fundamental systems question: early fusion or late fusion? Multiple sensors, you have to combine them! Early fusion means merging raw data from all sensors before any interpretation. Late fusion means interpreting data from each sensor independently, then fusing the results. Pick your poison. You can spend man-years on late fusion and end up switching to early. Or vice versa. There's no clear “right” answer— and attempts to combine both just explode KISS entirely (that was a little joke). Organizational Drag: The LiDAR Silo Add a new modality like LiDAR and you’ll usually hire specialists for it. That’s where the next trap lies. These engineers tend to become territorial advocates for their sensor— whether or not it’s the right tool for the problem. And their go-to solution when things don't work? “We just need more engineers.” That’s how a technical issue becomes an organizational problem. (My approach. Hire a subject matter expert (SME) if you must, but never build an isolated team around them. Keep the whole engineering team intact and make everyone work the full problem. Look for “smart”, not “expert.” Be wary of anyone who leads with their resume and won’t learn something new.) Testing, Integration, and the Iceberg Below the Surface With multiple sensor teams, you now have to test both in isolation and fully integrated. But full integration is where things break— technically and organizationally. Integration done late leads to broken assumptions and finger-pointing. The solution? Integrate early and often. Yes, it slows you down. But it pays off in the end. The Vendor Problem Many LiDAR units come with heavy vendor-side abstraction. You're not getting raw data— you’re getting interpreted data. And that’s a problem. Your engineers will want to strip it down and get to the hardware. Vendors will push back, hard. Why? Because if you’re using raw data, you can swap them out. They lose lock-in. They’ll guard that abstraction layer fiercely. Meanwhile, your team is probably thinking, “Should we just build the damn sensor ourselves?” And now you’re neck-deep in the build vs. buy debate. Another layer of complexity. Complexity Kills So now you’ve got: -A potentially bloated, complex system -Interdependencies across multiple teams and vendors -Difficult-to-verify behavior -Slow response to change or failures (which in itself is a safety issue) -A much longer path to delivery If you're betting that all this complexity adds safety, ask yourself: What happens when something goes wrong? Can you fix it fast? Can you verify the fix? Or are you stuck because nobody really owns the whole stack anymore? It’s not just that the system is complex. It’s fragile. And that fragility shows up in the real world. Real engineering is hard. Few learn the lessons of KISS. And armchair engineers and media pundits offering “solutions” are clueless about the real complexities under the hood. They’re spectators mistaking commentary for contribution, with an inflated ego or agenda or both. — *The robotic assignment was, on the surface, quite simple. Two robots had to communicate with each other—actually, even simpler: one robot had to "speak," and the other had to receive the message accurately. The assignment had two goals: communicate as accurately as possible (the first-order goal), and as fast as possible (the second-order goal). Each robot had a speaker and a microphone. The speaker could generate tones in a certain frequency range for specified durations. The microphone could pick up those waveforms, your code got to interpret. We teamed up in pairs—me and my highly intelligent roommate, Jack. We knocked it out in two hours. How? Using KISS. While other teams spent hours in the lab tweaking frequency ranges and experimenting with complex encodings, we kept it simple: fixed-frequency Morse code. Duration was our only variable— the length of each tone. We coded it up in no time and had 100% accuracy right out of the gate. Then we wrote a test program to gradually shorten the tone durations (both long and short Morse tones) until the receiver started making errors. We backed off and fixed it to the last 100% accurate setting. We won the competition with the most accurate and fastest communication— and spent most of our time on the racquetball court instead of the computer lab. KISS. **Elon’s 5-step Engineering Process: 1. Make the requirements less dumb 2. Try very hard to delete parts or processes 3. Simplify or optimize the design 4. Accelerate cycle time 5. Automate