Comment by joezydeco | Hacker News Reader

Comment by joezydeco | Hacker News Reader

Parent Full thread

Because the engineers get a directive to jump to a new platform (like Tizen) and they're handed a barely-working reference platform with a HelloWorld app on it.

Then they're told "oh yeah, this has to be ready by the Christmas selling season, which means you need to lock down firmware by July 1st. And we're demoing it at a trade show in May." And it's already April.

So the engineers comment out printf("Hello World\n"); and start writing a camera. And so on. If they remember to take the other crap out of the Makefile (including the demo pictures of Obama), that's probably because they ran out of space in NOR Flash. Otherwise it stays in. Is there time to run network hidey-hole testing on the WiFi stuff? They're probably happy the thing takes a picture without wiping the SD Card a this point.

It's all bubble-gum and duct tape underneath it all. From your Toyota auto to your Samsung camera to the Smart TV on your wall to the KitchenAid LCD oven in your house.

What's with your comment about the Toyota auto? As I understand there's a hell of a lot more regulation, forcing automobile product time lines to be naturally longer.

He is taking a cheap stab at a budget car manufacturer. Probably owns a Tesla. Or two.

Actually I drive a Toyota. But it's a 1996 model. ;-)

"Toyota’s developers used MISRA-C and the OSEK operating system, both good choices for a safety-critical real-time system. But then they ignored, sidestepped, or circumvented many of the very safety features they are designed to enforce."

"On a cyclomatic-complexity scale, a rating of 10 is considered workable code, with 15 being the upper limit for some exceptional cases. Toyota’s code had dozens upon dozens of functions that rated higher than 50. Tellingly, the throttle-angle sensor function scored more than 100, making it completely and utterly untestable."

http://www.eejournal.com/archives/articles/20131127-toyota/

Michael Barr was the engineer that was able to sit down with the Toyota engine code during the "unintended acceleration" lawsuit and determine what NASA could not: that the code was a wreck:

http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyo...

Like I said. Bubble gum and duct tape.

The regulations only apply to the engine computer (which is probably not changed much in each model year).

There is no strict quality or safety (or aesthetic, for that matter) regulation for the entertainment/climate control system user interfaces.

(In case you've ever wondered: yes, these screens do often show information from the engine computer. For example, the 2nd generation Prius's center console screen shows live information about the hybrid system. But that information is pretty much always obtained from a read-only connection to the CAN bus.)

It's a bad example because "toyotism" is widely considered synonymous with valuing precision[1] and efficiency[2] in production with ever-increasing quality.

It would be less notable, though, if not for the contributions that Toyota brought to the craft, which are basically the same that today's developers apply so pridefully in their work.

[1]: http://en.wikipedia.org/wiki/Lean_manufacturing [2]: http://en.wikipedia.org/wiki/Kanban

Regulation doesn't make software better.

I don't know about Toyota specifically, but I work for a regulated sector, and the end result is that we generate documented and ISO 9001:2000 - compliant duct tape and bubble gum :P .

Have you noticed that ISO9000:2000 is a lot more relaxed than ISO9000 was in the 1990s? You have to wonder if so many projects were failing that they eventually decided to move the goalposts closer.

I never got to see the older ISO standard :) (I entered the workforce in 2002) so I'll take you at your word.

It does seem to be not that hard to attain a certification.

Nothing is a panacea. Regulation can encourage better engineering practices, and that can certainly make for better software.

The existence of false positives doesn't mean the whole exercise is pointless.

I agree that regulation might point you in the right direction, but if the company is not commited to quality, I think it's very hard (and unlikely) for regulation to make the company change its bad habits. What I've seen is regulation stifling change, freezing projects, and creating more bureaucracy.

In the particular company I work for (financial sector), there has been an increase in regulation and auditing of security practices. They're still really bad, you've seen endless posts here decrying the awfulness of some banking security practices. The worst thing is, they've probably been audited and made to pass some kind of regulatory standard, and the very fact they had to go through all that makes it harder to change (even if they're awful) since managament isn't willing to authorize it, especially since it doesn't affect the bottom line.

If more people have to resign (like the Target CEO), maybe things will change, but I suspect IT people will become scapegoats instead.

Agree that you have to actually be committed to improving the quality, you can't paper over holes in this and expect good results. If there is genuine disinterest at the management level in making better quality software for whatever reasons, you're probably screwed regardless of what you try.

You can lead a horse to water...

Probably talking about the in car infotainment system.

Reply on news.ycombinator.com