SoylentNews is people
SoylentNews
Tesla CEO Elon Musk has accused a Tesla employee of "quite extensive and damaging sabotage to our operations," according to an email obtained by CNBC. In the all-hands email to Tesla staff, Musk wrote that the employee had made "direct code changes" to the company's production systems, as well as exporting "large amounts" of Tesla's data to unknown third parties.
According to Musk's email, the unnamed employee claimed he had become disgruntled after failing to receive a promotion. However, the Tesla CEO also suggested the alleged saboteur could have been working with short sellers, oil and gas companies—whom he described as "sometimes not super nice"—or "the multitude of big gas/diesel car company competitors." Of this last group, Musk reminded his employees that, since the traditional OEMs have been known to cheat emissions tests, "maybe they're willing to cheat in other ways."
[...] Tesla has faced plenty of criticism about its ongoing troubles in ramping up Model 3 production. But that may have been unwarranted if those problems were due to sabotage. We reached out to Tesla regarding CNBC's story, but the company declined to comment at this time.
(Score: 1, Interesting) by Anonymous Coward on Wednesday June 20 2018, @05:27AM (1 child)
I know nothing about what Tesla's running in their plant, but I do know a thing or two about process automation. So, on the subject of code reviews... 'real' software (like the browser I write this in or the kernel that runs the operating system on this PC), and PLC or other automation software (like the stuff that runs assembly lines and other industrial equipment), are two totally different beasts that happen to share the name software.
Sure, you can use git (or whatever other vcs you prefer) with it, but it's almost entirely binary files as far as the vcs is concerned. It's not like C source code. It isn't text files and diff/patch is not going to produce human-readable output. Siemens, Allen-Bradley, Parker IQAN, Opto, the brand doesn't matter. None of them are comparable to a normal programming language and IDE, none of them use flat text files for anything important, and none of them
Unless your standard code review procedure includes sitting down with the code writer and review panel, with a projector and a pc running the development software, and then stepping through the flowchart/ladder-logic/whatever-that-brand-uses step by step, in which case sure, for a Monumental investment in manhours, a code review is workable. To be fair, I've never worked at a company that would be capable of doing that. It might be kind of nice. Or it might be a nightmare. I'd rather not find out.
In fact, lets back up. Describe the process for a typical code review please, maybe I'm way off base in my assumptions, here.
(Score: 3, Informative) by tangomargarine on Wednesday June 20 2018, @03:53PM
In a funny coincidence, I actually did a contract at Rockwell (who acquired Allen-Bradley some time ago) doing unit testing on one of their embedded teams a few years ago, so I'm not sure how much I buy "none of it's human-readable." Low-level C is of course nowhere near as readable as higher-level projects, but yeah. The developers on the team did do code reviews.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"