Monroe & Associates has been tearing down cars and other things as their sole business for quite a while. https://jalopnik.com/the-fascinating-company-that-tears-cars... is a pretty good overview of their business and the insane depths of knowledge that their engineers have.

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.

It makes sense. Munroe knows their stuff and it could be wise for Tesla to employ their services at some point for a little analysis. Such a cool and obscure business. There’s a little doc about the company. The extent to which they breakdown and analyze a product is anxiety-inducing.

The only reason Tesla is making bad decisions is because of schedule, everything else stems from that. That said I am pretty positive on Tesla because even thought they release half baked products they still improve and innovate at a breakneck pace. Turns out shit happens when you have a charismatic leader attracting a bunch brilliant and driven people and telling them to go change the world.

Would you be happy that your $70K car was "half baked" so that Tesla could improve more rapidly?

Interesting parallel question: "Would you be happy if your $800 phone didn't have copy-paste functionality, no 3G, and no app store?"

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

It's an interesting parallel to consider because iPhone was revolutionary, it was something no one had seen when it came out, it was literally the first smartphone.

So, are you saying Tesla's cars with their design flaws are revolutionary like the first smartphone?

It absolutely was not the first smartphone; Nokia E-series predated by several years.

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.

Yes.

Mass produced viable electric cars, with a mileage of 300 miles.

A bigger revolution than the iPhone.

Yes, go test drive one and see for yourself.

My phone can't kill me, nor others.

Good thing body panel gaps don't kill many people as well!

I would not, which is why I do not have a model 3. People who have Teslas right now are early adopters.

A question back: would you be happy if Tesla did not kick-start electric car ramp up?

I don't own one; don't plan to buy one. So I'm indifferent.

I’d rather the structure were over-engineered where it counted.

They've been in the business, probably are experts at cost reduction engineering. Their business is selling this information to other auto companies so they must be right enough that they can get paid for it.

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.

Or what's more likely is that Tesla didn't decide to make giant flanges because they're idiots, and they're not going to outright tell M&A what the reasoning is, because this is exactly the information they want to be able to sell to other auto manufacturers.

Munro and Associates was an engineering consultancy known for reverse-engineering not just automobiles, but everything from airplanes to household items like rice cookers, to learn how they work.

A previous tear-down was a lot harsher https://jalopnik.com/tesla-model-3-teardown-by-engineering-f...

Believe it or not, that's referring to the same teardown as this article. It is a multi-month process.

> Is the intellectual asymmetry between creating a design and analyzing it so large that a small teardown team can reliably analyze trade-offs in a design created by a large engineering group?

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.

Munro and Associates is the firm that does this kind of analysis in the automotive industry.

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.

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

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

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.

Do you want your bosses going to a firm like Monroe.

Because companies will occasionally send in their own product to see if they can squeeze their manufacturers and see what their engineers missed.

Yes, honestly, I do. I would absolutely appreciate detailed and specific feedback across all of my work.

How else are we expected to improve? Even when it's thing subject to opinion, I'd like to hear those other opinions.

I feel like you get a flavor of this for software by reading the mailing lists in the more mature open source project, you can basically get a continuous flow of analysis and build or rebuild. It's not packaged in a nice episodic report form, but you can get a little of that too with some projects.

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

No they are not. Car companies do not go to Munro, period.

There are far more reputable sources, speaking from someone in the industry. Munro is just trying to get free advertising with this sh*t.

That's interesting. Which sources are in your view more reputable? Where do you work? One of the big three or a Japanese carmaker?

Car companies do not go to Munro, period.

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.

> Car companies do not go to Munro, period.

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.

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

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.

You don't need to be an expert to criticize the user experience of a product. A reviewer who says "this phone is slow" is probably right. It requires much deeper knowledge to criticize internal details. A reviewer who says "they used too big a capacitor for C143" would need to understand a great deal about the design for that claim to be credible.

Most of the negatives in the article seemed to be of the second kind.

> f 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?

This makes no sense. Yes, if a reviewer doubts it, it means nothing unless they can prove it with numbers.

It's the same ot worse for phones, yes.

> Is the intellectual asymmetry between creating a design and analyzing it so large that a small teardown team can reliably analyze trade-offs in a design created by a large engineering group?

Is it easier to verify a solution to a problem than it is to produce it?

million dollar question.

Quite literally! http://theconversation.com/millennium-prize-p-vs-np-4246

NP means that a solution can be verified to be valid. Like the reviewer saying “yep, this is a car all right”. But verifying whether a solution is optimal is not generally even in NP.

You can use the decision version of an optimization problem to answer the optimization problem.

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.

That technique isn't as powerful as sometimes believed. In your example, you've assumed the uncomputable thing, an algorithm which reliably produces a solution to a problem for which one exists. Consider, "Is there a proof in fewer than x lines of the Riemann hypothesis?"

I don’t think that a candidate solution to your problem statement can be deterministically verified in polynomial time.

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.

Verifying a solution is harder than producing one. Identifying a flaw in a solution is easier than either.

Not sure what you are referring to -- at least in the P/NP problem complexity classification verifying the solution is easy, coming up is P/NP-hard, i.e hard.

So if I gave you a flawless solution to a sudoku problem, would you tell me that it was harder for you to verify it than it was for the solution to be produced?

I had to do exactly this in a practical coding interview. Fun was had.

I think that really depends on the problem space. If I had to hire a sales team to increase revenue, then I hire them and check the revenue numbers (with basic accounting for other secondary variables), its pretty straight forward to validate.

Munro claims to have a lot of engineering an tear down experience. I guess that's what they sell. That said I don't expect them to be 100% correct on all the trade-offs.

Wouldn’t those larger flanges provide stiffness for a car that is much heavier, and can deliver to the wheels a boat load more torque, than similar sized ICE powdered cars.

And yeah, an electric motor is going to have vastly different vibration characteristics than an ICE.

agree, and would like to add that businesses can either spend time on figuring out the most efficient flange design or spend that time on improving a feature that will bring higher customer value. I would suspect most people are not buying cars because the flange is not the perfect size, or that there are overlapping panels.

Take any gen 1 product apart from an innovative company, I am sure you will find skeletons.

So long as customers buying those gen 1 products know what they are buying. No company will transparently disclose their skeletons, so I'm glad we have reviewers that do.

It seems as they can't reliably analyze the decisions.

>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

For a lay person, sure. But these are experts at automotive engineering. Imagine if you were reviewing a new developer's code, and you were puzzled by a particularly non-idiomatic implementation where you can't see the reasons for avoiding the idiomatic version. Are you going to think that maybe this is some technique you're unfamiliar with, or that the person who'se still quite new to developing might not be aware of the idiomatic verions?

So a good example of this in code would be:

    a = a xor b; b = a xor b; a = a xor b;

In this case it is a technique for swapping two variables without using a third variable. But it really serves no efficiency purpose in most applications (however it is fun to use).

Which comes with the obligatory reminder that it fails when a == b.

No it doesn't. xor swap works fine when the two values are equal. The problem is when &a == &b.

I get where you're coming from, but Tesla engineers have seen those flanges and that extra steel in crash tests where these engineers have not.

Your example would be more akin to assessing someone's code and pointing out potential flaws without ever executing it.

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

On the other hand: "take note that I have only proven this code correct, not tested it." Code review is performed in the understanding that its results are basically heuristic. Everyone knows that actual behavior trumps anything you get from just looking at something.