For example, when they say "this flange is larger than necessary", how can they know all the possible reasons it might be necessary? Perhaps it adds stiffness or crash energy absorption, or is used to grasp the part during assembly, or avoids a resonant frequency.
They’ve accumulated a ton of knowledge about How To Cars. Of course it is possible that Tesla is making a bunch of design decisions that M&A thinks are weird because they are optimizing for very different things than most other carmakers; it would be pretty interesting to be a fly on the wall in a discussion between Tesla’s engineers and M&A’s.
A question back: would you be happy if Tesla did not kick-start electric car ramp up?
It's an interesting question to consider because that was basically what the iPhone was when it launched. It was behind the state of the art at the time in many important ways (not having 3G was a big deal), but it was so incredibly far ahead in several very critical ways (multitouch display, 100% touch-based OS, full fledged browser, next level music player) that it didn't ultimately matter.
Now the question is, does Tesla strike that balance? The second question is, can they iterate rapidly and close the gap (which the iPhone ultimately did)?
So, are you saying Tesla's cars with their design flaws are revolutionary like the first smartphone?
Mass produced viable electric cars, with a mileage of 300 miles.
A bigger revolution than the iPhone.
Nor was it the first keyboardless touch-screen phone, that was the LG Prada.
The iPhone was a clever subset of well-polished features very well marketed. The usual Apple approach.
There are potential reasons why the mentioned flange might be oversized, I'm having a hard time imagining how they tested frequency resonance and decided to just fix it by leaving a little extra material near where the welds go though. Or likewise deciding that the extra material in the weld zone increases safety by some margin. Those possibilities seem like they'd require and extremely nuanced and subtle understanding of the car and the whole process, It's possible, I guess. What's far more likely is that they just haven't done a round of cost reduction as they're just struggling to get the initial manufacturing done for the pre-orders.
A previous tear-down was a lot harsher https://jalopnik.com/tesla-model-3-teardown-by-engineering-f...
I don't understand this. So you are saying the reviewer's small team doesn't understand the expertise which might have gone in the car.
But isn't that true for every product review and article out there? Take for example a phone. If a reviewer doubts the CPU benchmark on a phone, are we going to talk about how a single reviewer cannot understand the trade-off a bigger team at Apple/Samsung/Google has put?
Or if a journalist talking about FB's decision on data sharing has the capacity to know the trade-offs made by a much larger technical and business group at FB.
We can only look at the past work. If HN is voting this up then we know these guys have done some good work in the past.
Unless of course we think everyone who doubts Tesla's expertise doesn't understand their genius.
It's really fascinating. For the record, it would be hard to produce a design that Munro couldn't find something to talk about, good or bad. They employ extremely gifted engineers with a ridiculously large amount of experience at doing this exact task.
As a software engineer, I wish there were an equivalent firm in the industry that did teardowns like this so that we could, as an industry, improve over time the way that the automotive industry does.
I feel like it may be one of the factors holding software engineering back from achieving true professional engineering standardization.
There are far more reputable sources, speaking from someone in the industry. Munro is just trying to get free advertising with this sh*t.
Really? So where do they get their income?
The comment below has some questions for you. This is all information you would have provided if you actually knew what you were talking about. The fact that you didn't leads me to think you are a troller who just likes to say things that make people angry.
I don't know if you're trolling or what, but the truth is interesting. None of the US domestic automakers buy reports from Munro. They sell information to Japanese, Korean, Chinese and European automakers.
For the software industry as a whole, the closest thing might be the SEI[1], but that body of work takes some effort to work through, perhaps suffering a bit from a more adademic roots vs a more industry engineering info exchange approach like M&A. For that you might have specialist areas, for example, the Jepsen tests and blog[2].
[1] https://en.wikipedia.org/wiki/Software_Engineering_Institute [2] https://aphyr.com/tags/Jepsen
There are quite a lot of security companies that reverse engineer other software products and publish their findings. It would be good to see that for non-security stuff too.
Because companies will occasionally send in their own product to see if they can squeeze their manufacturers and see what their engineers missed.
How else are we expected to improve? Even when it's thing subject to opinion, I'd like to hear those other opinions.
I think this thread is a good indicator of why that might never happen. People in software will argue with whatever stuff they can and try to refute a review/teardown - reviewer doesn't understand the design consideration, reviewer don't have numbers, the stuff is revolutionary etc etc.
The equivalent for the GP's claim would be the reviewer claiming that a phone's CPU is underpowered and that a more powerful one could have been used instead. That assumes a lot of knowledge about the tradeoffs that the phone designer had to consider - technical, logistical, financial, etc.
I don't know anything about Monroe & Associates' expertise, but I agree with the GP that this is a high bar to clear.
This makes no sense. Yes, if a reviewer doubts it, it means nothing unless they can prove it with numbers.
Most of the negatives in the article seemed to be of the second kind.
Is it easier to verify a solution to a problem than it is to produce it?
million dollar question.
For example when you're looking for the fastest route, you're not directly asking "is this the fastest route?" You're asking "Is there a route shorter than length x?" It's a yes or no question, that's easy to verify given a certificate. If the answer is "yes" then the certificate is a route produced that is shorter than length x.
Assuming the existence of an algorithm that can reliably produce a verifiable "yes" with a certificate or "no", you ask "Is there a route shorter than length x?" and if the answer is yes (which you can easily verify), you keep reducing the length of x in the question until the answer to the question is not yes (no certificate can be produced). The certificate of the limiting "yes" is the optimal solution.
Any candidate solution produced would be subjective to the interpreter who is verifying it as to whether it satisfies the requirements of a proof (maybe they want more definitions, less shorthand notation, maybe in french, references in APA style with full names, etc, all of which would effect the length of the proof).
So whereas a candidate solution to your question is difficult to verify, it is not in this P vs NP discussion.
And yeah, an electric motor is going to have vastly different vibration characteristics than an ICE.
Take any gen 1 product apart from an innovative company, I am sure you will find skeletons.
>highlighting areas where Tesla needlessly added weight with things like excess metal flanges and overlapping layers of steel. "This adds weight without value," he said.
it feels rather presumptuous to assume that the added value isn't safety.. which isn't something you can assess in a teardown.
In the next paragraph:
"He was also puzzled by Tesla's unconventional use of multiple welding techniques in close proximity to one another. "I don't get it," he said. "There's a lot of technology [used] here, but what we don't understand is why they used the technology they did."
Not understanding something != bad
Your example would be more akin to assessing someone's code and pointing out potential flaws without ever executing it.
You've just described a code review, which is standard practice and not controversial. If an expert doesn't understand your code, maybe the criticism is informed by their experience.
a = a xor b; b = a xor b; a = a xor b;