Tesla faked self-driving demo, Autopilot engineer testifies Allegations that Tesla staged a 2016 video demonstrating full self driving have resurfaced, and this time it's not an anonymous source making the claims – it's testimony from Tesla's own director of Autopilot software, Ashok Elluswamy. In a partly redacted deposition [PDF] from a 2019 civil case, given in June last year and …
Here's a very old quote that essentially describes what is still happening today ... Doug was talking about software issues but the concept that he described happening back in 1968 applies to everything these days - I just spent this morning hearing all about these types of problems ... optical software "performing measurements" as someone walks, but every "measurement" is in millimeters - here's one:
X=4.274241216, Y=1.355787776, Z=5.937175968 ... can you measure distances with a resolution of 0.000000001 mm, how big is an atom?
"The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers' ignorance before they started the job." -- D.T. Ross, NATO Software Engineering Conference, 1968
I understand that when a building is put up, the builders are supposed to supply an "as built" plan to correct the original architect's and engineer's "as planned" plan. I don't know how often they actually do so, but either way, I wish this were done in SW development. .
In an Agile project I was involved in, the spec for each sprint was published, but more often than not, something had to be changed along the way. The changes were never documented. The net result was that there was no written documentation for the program "as built"; knowledge resided in the recollection of the product and project managers and developers. Since I was an add-on to the project, in a product management role, in order to design (and assist in the implementation of) a particular facility, I did quite a bit of testing to make sure it worked in context.
Once I saw something surprising happen and asked someone who had been on the product management team at a high level for a long time, "What is the program supposed to do when X happens?" He couldn't tell me. He said, "Why don't you try it and see?" Well, I had already tried it and seen, but it was not satisfactory. What I was really after was "What is SUPPOSED to happen" in this situation. I didn't know whether what I had seen was an implementation failure or a design failure.
IIRC, the lamented Fred Brooks said that every project of any size require a "Librarian", to keep track of project documentation and keep it up to date. That book was written in the waterfall era and I think technologists using more recent development paradigms have largely assumed that this role was no longer required. But my (limited) experience, described above, leads me to believe that it is needed as much in the agile era as in the waterfall era, or maybe even more so.
Documentation (or the lack thereof) is a great source of technical debt. "The code is the documentation" is another classic, as nobody but the programmer can read it, most of the stakeholders and domain experts have zero access to it, and of the 8-9 out of 10 people who may have any reason to touch it, it may be the singe worst form for them to consume or understand that information in.
For any non trivial project, keeping the project documentation up do date has a non-trivial cost. The cost of not keeping the documentation up do date is very non-linear, as is the time and effort to play catch-up.
If your sprints are short enough, completing the updates as you deliver the rest of the work for the print may be manageable, but it won't scale well and builds bad habits. It's also not really agile, and breaks any semblance of change management.
As to the Librarian Hat, I have worn it. You can share or pass it to whoever you want, but the work is still hiding, and still needs to be done. That isn't a "waterfall" trait, it's a project management and change management problem. Many people appreciate not having to be the keeper of the book of armaments, but cut the role at your peril lest ye attempt to count to five and run into bumps along the road.
Not all the documentation is necessary. Too often developers wrote countless manuals no one ever opened.
This doesn't mean documentation isn't necessary at all. One is crucial for a project success: it's having written specifications, on which as the customer as the supplier agree it's the contract between them. Both can refer to them in case of disagreement.
No written specifications = disaster on the way
"Too often developers wrote countless manuals no one ever opened."
Though that doesn't necessarily mean those manuals are of no value to the project. Over my quarter century of professional engineering to date, something I learned early on and continue to make use of is that sometimes just sitting down and starting to document a particular aspect of the design is a bloody good way of helping to focus your mind on what it is you're trying to achieve in that part of the design, what the pitfalls might be, and how you can design a solution. Essentially, the written documentation you end up producing acts a bit like a hardcopy for your mental thought processes, but because you're writing it down as you go then the act of doing so interacts with your thinking in positive ways.
Whether it's purely because you're having to slow down your thoughts in order to capture them, or because of some deeper entanglement between the different parts of your brain that deal with the original thoughts and the physical act of writing about them, I wouldn't even want to begin to suggest an answer. All I know is that, every time I've done it on a project, it's had the desired outcome. And at the end of it, I've then also got a bit of quite detailed technical documentation that can be referred to at a later date if so desired, but if someone else does read them then it's just a nice bonus - that was never the intention behind writing them in the first place...
Having just watched the miniseries 'The Dropout', the story of Elizabeth Holmes and her start-up company Thenanos, there seems to a few parallels here, with Tesla's Auto Pilot.
Just the same with Apple, we're still waiting for a version of iPadOS that lives up to the quality of the iPad Pro hardware, and takes advantage of it.
Is anyone surprised?
"can you measure distances with a resolution of 0.000000001 mm, how big is an atom?"
Well, the size of an atom is generally measured on the angstrom (Å) scale (~10−10 m). So yeah, measuring down to 10−12 m seems slightly infeasible. General experimental errors aside, you'd start to get into Heisenberg territory.*
Also, anyone surprised that they effectively lied? That's one hell of a misrepresentation, and given the subsequent lethal consequences this could have consequences.
The next question will be if those lies were directly commanded by El Genius who isn't, Musk. I suspect they are, but proving that may be hard - still too many sycophants around willing to cover. The similarities with Trump keep on coming.
Speaking of the orange problem, he's been asking to be allowed on Facebook again, a perfect reason to finally abandon that too.
Should have been denied with extreme prejudice resulting in a summary decision against Tesla.
Not at all suprising they tried to pull that, but I am surprised it's allowed to happen.
Anyone trying to prohibit evidence that could make them look guilty should suffer the same. Evidence should certainly be challenged for veracity, but it should be impossible to prohibit such depositions.
It is a demo what their target is, what they want, not of what is possible in 2016. It is meant to be a tech demo, and never anything else, so there is nothing to fake. Everybody knows, and it is sooo obvious too see. Well, except for that one country which has quite often difficulties to grasp reality, as it seems.
"It is a demo what their target is, what they want, not of what is possible"
We know what "car driving correctly without person operating it" looks like. We don't need a video to show us that, and if you wanted to make one, you could always cut out the driver in editing. The point of a tech demo is to demonstrate the technology, and they specifically failed to show what the technology is capable of to mislead people who would be paying for it. If I showed you a device doing something which turned out to be a faked demo of a feature that might be added in a decade or so if I get around to it, you'd return the product and demand a refund and you'd be right to do so.
So then why isn't there anything which says that at the beginning?
This is yet more bullshit along the lines of Autopilot and Full Self Driving to befuddle prospective customers and give the impression they're ahead when it comes to driving assist, which might have been the case for a few years but not now.
If you remember his battery-powered deathtraps were supposed to be driving from LA to New York 6 years ago. There's so much nonsense thrown about that people who don't own one of his cars can't tell what it's supposed to do, which is how they sell them.
Nobody knew anything of the sort.
For a start you're contradicting yourself; a tech demo and a video of what their target is are two completely different things. A tech demo is a demonstration of what the technology can do now. Something showing their target isn't in any way a tech demo, it's science fiction.
Secondly if it were just a video showing what they hoped they could achieve in future they would have stated that, they didn't. Quite the opposite - the message was look what we can do! The whole thing reminds me of a video of a "self driving" truck I saw a few years back. Yes it was partly autonomous, but it still needed a driver it was just that the driver was not in the truck but controlling it remotely. The schtick of the video however was that the truck was self driving.
And finally, you're obviously one of those big fans who doesn't actually deal in facts. You are aware it's not Apple we're talking about?
> And finally, you're obviously one of those big fans
You only have to check what I write on TheReg forum Tesla in other articles, not even a google search needed. Just check before jumping to a conclusion. Or are you just like those grown-ups from Southpark which do that all the time?
While this was promotional, it didn't come with such provisos and disclaimers. Any student of US tort law will know that the "man on the Clapham omnibus" defence is no use whatsoever. And, because damages can be unlimited (depends on the state), lawyers are normally all over such releases before they happen.
Tesla's image will be tarnished forever. Oh, how the mighty have fallen.
> Any student of US tort law
As you wrote, "US". Only there such laws are needed since way too many lack common sense. Hence the reason why every microwave has that "no dogs please" in their manual. And every rear mirror has "Objects may be closer than they appear" engraved, which shouldn't be required. Luckily the US-A is big enough to still have a large amount of people with common sense, tough declining...
Yes, but this is a tad more serious as it kills people. If it killed only its buyer/driver, OK, fair enough-ish, they made their choice. But the rest of the road users never asked to become test dummies in Musk's lethal experiments. Yes, experiments, it's still called "beta" to pretend it'll be better at some point as an excuse why it doesn't properly work right now, yet they're asking quite a smack of money for drivers to incur this dangerous liability.
Before Tesla, only Microsoft got away with changing people for what is in essence a beta (at best), which they are still doing now. Tesla doing this in real life is not good.
Is this really about Autopilot, or about FSD?
Autopilot (as far as I understand) is actually the really dumb name for how it beeps at you if you get too close to the person in front of you, etc. That’s real and has been around for a long time.
FSD is the fraud/fantasy portion of the thing.
As soon as you have sales people on staff, you'll have gross exaggeration. They'll have a set idea of what the product can do (mostly imagination) and the engineer will have an serious vision of what it can't do.
Then as these two will not talk about daily these two aspects grows a huge gulf between them which gets wider over time...
Happens every time with every project.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
