4 ms·
> Western developers are obsessing over the latest JavaScript framework or arguing about tabs vs. spaces Most "Western developers" are not doing that; this is
by arp242 1y ago
> Western developers are obsessing over the latest JavaScript framework or arguing about tabs vs. spaces
Most "Western developers" are not doing that; this is a minority.
I don't really know anything about Japanese software development, but I'm reasonably sure there are some Japanese developers doing unreasonable things too.
e.g. was that Toyota firmware that caused acceleration developed in Japan? An audit revealed it was absolutely horrible.
- rstuart4133 1y ago> e.g. was that Toyota firmware that caused acceleration developed in Japan? An audit revealed it was absolutely horrible. It's horribleness was a line pushed by the people trying to get money out of Toyota. From their descriptions it seemed in line with proprietary code that it's owners never expected to be exposed to sunlight. The way the code was described, it sounded like it had grown organically for a long while. Features tacked on here and there, no obvious attempt at formally ensuring deadlines in real time critical software (like braking systems) were met. Instead they tacked on features, then subjected it to what must have been a truly formidable testing regime, and fixed any failures with more hacks (like resetting the machine if invariants were violated). Well, maybe. That's a guess. It's seems be in line with the process Toyota uses for all its car engineering, from light bulks to engine rings. They applied the same engineering process to software. Given they produce the most reliable line of cars on the planet, it's hard to be too critical. And it worked in this case too. No serious (ie, life or equipment destroying) bugs were found on Toyota's code. No one knows for sure what the problem was, but suspicion is noise caused a bit flip sending NEC MCU off the rails. But not in Toyota's code, because every variable was stored in 2 places, every read compared to two values and if they weren't equal, the MCU was reset (I think?). However, the OS Toyota used was a proprietary one from NEC. They didn't have the source for it. I think they assumed it was at robust as their code. They were wrong. And by flipping a bit in the scheduler's variables (which weren't duplicated), you could cause the exact symptoms that lead to the crashes (engine stuck at full throttle, ECU off in lala land). I came away thinking their mistake was to treat software like a piston rod. You don't have to see a piston rod being made. You can test the materials when you get it, you can x-ray it, you can deliberately push it to destruction, and most importantly if you do that enough times you can create a statistical model about it's behaviour. But software, particularly closed source software embedded in an MCU that can change without notice anytime, isn't like that. Still, Toyota didn't come out of this smelling like a rose. Rather than transparently investigating the problem, they hid everything for as long as they could, tied everyone up in legal knots, and counter sued. Anti-social behaviour IMO. Everyone, including them, would have benefited in the long run by an open and transparent investigation into the root cause. Still, it's hard to criticise their engineering. Them being screwed over by NEC hiding stuff from them (their customer) just as they hide stuff from their customers else is karma, baby. I hope they learnt something from it.