Why Japanese Developers Write Code Differently (& Why It Works Better

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

It mostly reads like they're exoticizing good development practice because they don't recognize it and/or haven't seen it elsewhere.

On the other hand, SV development culture is often obsessed with early release and adding features, traits I would identify with short-termism, rather than improving usability and minimising bloat (trends not rules). So a little old school conservatism might go a long way when it comes to software.. although the problems of too much silence in the face of seniority are also well known from the airline industry.

Agreed, it's cherry picked and strange since a lot of western developers already profess a lot of these practices -- especially the "extensive comments" and "descriptive naming" points.

It reminds me a lot about "innovative Japanese management solutions" which consists of MBAs learning what a bottleneck is and that DevOps is just sensible basic business practice.