6 ms·

After having lived and worked in Japan, this doesn't surprise me. Software engineering education is really weak there, managers who became managers because of t

by song 11y ago

After having lived and worked in Japan, this doesn't surprise me. Software engineering education is really weak there, managers who became managers because of their seniority tend to impose their own antiquated decisions and do not listen to best practices. The other problem is that status wise, it's considered lower level to be a software engineer than to be a mechanical or electrical engineer, so the smartest kids do not study computer science (this might have changed since).

ild 11y ago
> it's considered lower level to be a software engineer than to be a mechanical or electrical engineer, so the smartest kids do not study computer science (this might have changed since). Which is very interesting, because in US it is completely opposite (and frankly it is not good either). Is it because US deindustrialized itself last 40 years?
- thrownaway2424 11y ago
  Did you mean "Deindustrialization or deindustrialisation is a process of social and economic change caused by the removal or reduction of industrial capacity or activity in a country or region, especially heavy industry or manufacturing industry." ? That doesn't sound applicable to the USA, which currently produces more goods than ever before, and more than any other nation except China.
  - peterfirefly 11y ago
    It does so with far fewer people than before, though. In that sense, there has been a "deindustrialization".
  - ild 11y ago
    I am talking about industry as share of GDP. Check the numbers: http://en.wikipedia.org/wiki/Economy_of_the_United_States_by_sector http://en.wikipedia.org/wiki/Economy_of_the_United_States_by.... Manufacturing kept going down.
- SiVal 11y ago
  It was not the opposite in the US 30 years ago, when I chose EE over CS, because EE was clearly more respected as being the more intellectually demanding. This had a lot to do with the capabilities of hardware at the time and the locus of value. IBM sold its hardware for millions. It gave away the software. The hardware was the differentiator; software was generic. EEs who could improve the expensive hardware were a lot more valuable than programmers who could improve the free software. In fact, since doubling a hardware resource such as RAM far more than doubles what you can then build with software, the hardware guys were more important than the software guys--even to the software. As hardware limits were relaxed over the years, what you could accomplish in software, even with cheap hardware, grew so enormously that the primary value was increasingly in the software. This was such a rapid transition in the computer industry that it nearly destroyed IBM, it propelled Microsoft to power, and I ended up with a career in software. Toyota and other Asian "hardware" vendors are in some sense where IBM was. They sell prize-winning hardware and whatever software that comes with it is essentially free. (Apple is a lot like this, which is why their hardware keeps getting better and their software--well, did I mention the hardware is thinner?) The Toyota "platform" still can't do much in software, but it's growing exponentially. Eventually the software in a car might matter more than the (commodity?) hardware, but that's not the world in which Toyota managers were formed. They are obsessive about hardware, but software is an afterthought. It's for guys who couldn't cut it as "real engineers", as was the case in the American "computer industry" until the 1980s. I also lived and worked in Japan. I was a strategy consultant, and I was told by some big Japanese and Korean companies (whom everyone has heard of) to emphasize my hardware background and not be seen spending too much time hanging out with the software guys if I valued my reputation.
  - mirsadm 11y ago
    Apple is not like that at all. Their software is excellent. My guess is that a large percentage of their customers keep buying their hardware because of iOS or OS X not because it's thinner.
rdtsc 11y ago
There was an article about this (in New Yorker, I think...) a few years back, t how Japan has this strange relationship with software. How it is a hardware-first country. Many reasons were given -- cultural, how "real men build real things", infatuation with appliances, which are seen as being "hardware" in a way, perhaps the langauge barrier i.e. existing software tools using English for menus and inputs etc. And it is kind of interesting, looking back at a country that many in the 80's feared with surpass and leave the Western world in the dust technology-wise, we haven't seen that much software produced there. Can you think of large well known software from Japan (excluding console games). Vine Linux, SoftEther VPN, TrendMicro, anything else? One wonders if they see Western software companies and if there is any desire to catch up or try to keep up. Maybe anyone from Japan can provide a better perspective?
- karpodiem 11y ago
  let me know if you can find that New Yorker article, I'd be interested in reading it.
  - rdtsc 11y ago
    I think I found it http://www.economist.com/node/18958643 http://www.economist.com/node/18958643 it looks like it was in the Economist not New Yorker
    - karpodiem 11y ago
      thanks!
- cma 11y ago
  Why exclude console games?
  - rdtsc 11y ago
    I guess I see it as part of the appliance. Not something you download and install or use an API to access.
awongh 11y ago
This is also an interesting contrast to the (I assume higher quality) kind of work being put out by their other engineering departments- how can they make other sound engineering decisions on the rest of the car and it's manufacture, but fail at the software? Is it something specific to software vs. traditional engineering in Japanese culture, or is it something inherent to software in general? Given the parent's complaints about workplace culture in general, shouldn't the entire car be badly designed?
- hliyan 11y ago
  Exactly why I'm commenting so much on this. I always tell my team "Pay attention to detail, quality, method. Be more like the Japanese", to now see that even the Japanese (and their quality poster-boy no less) have trouble applying their quality philosophy to software. Not sure where that leaves my advice.
  - thaumaturgy 11y ago
    It doesn't change your advice. Toyota has a well-deserved reputation for quality in a lot of areas: customer service (they've been replacing frames on trucks for a few years at no cost to the consumer), construction, reliability, maintainability. That they have flaws in one area just means that they need to apply their practices to that area too.
- lifekaizen 11y ago
  I worked in new auto development at Toyota (Japan) for four years in mid 2000s, right before this happened. The unintended acceleration problem has also perplexed me, because in my experience any safety issue was always given top priority. But I did experience limited familiarity with software/firmware. Usually that was looked at as part of the component, for example the engine control module in it's physical plastic housing. Remember the production auto will have Denso (or similar) delivering that ECU to the factory as an "assembly" and hundreds or thousands of these are assembled into the car and function together. At the end of the assembly line, various tests are run on the system and vehicle, but these appear to be of the "input/output" that someone else described. So why isn't software done better? I'd say one problem is the testing process is not robust enough for software/firmware as it is for mechanicals. The tests revolve around driving the car, and variations on driving, and have evolved over years and decades. Heavy software control is newer, and in my experience was often not fully understood. Chief Engineers tend to come from mechanical. And there are always hundreds of problems to solve and limited time, and the black-box nature of firmware makes it hard to develop tests for. A development review meeting tends include various mechanical departments, like Drivetrain or Engine or Chassis, many times they bring physical prototypes to the meeting and the problems and proposed solutions are comprehensible. The build testing procedures subject the car/parts to various mechanical tests, and long-lead tests are performed which stress parts till breaking. It's something you develop experience with an can get your head around. Firmware bugs are not like that -- having just gone through this with my current consumer electronics startup I experienced the black box component first hand. I remember one software based problem we reviewed at Toyota, where something happened like: when the car has been sitting for >3 hours at <50F weather, and the ignition is started when the car is at a 15 degree angle (side of road) and driven on to a flat plane within 15 seconds, the "check engine" light turns on. Even though we had no test for that, we heard about it for customer complaints came through. But the fix is to have the supplier (in this case, but could be the Toyota engineer) fix that problem, with most of the discussion centered on timing and certainty of fix. I don't remember any discussions about global variables or lines of code.
abawany 11y ago
I can state that this matched my experience though I was in the US - this was in the 90s, and in the automotive industry. I used to work at Motorola Automotive and Industrial and our team built the Computer-Aided Manufacturing systems that managed the production lines. It always felt like a tier-2 job compared to process engineering.
enupten 11y ago
This is a genuine question: why can't they outsource their software devel ?
- Cthulhu_ 11y ago
  Given how they had the researcher effectively locked up in a hotel room with strict security measures, I'd say it's because they're terrified of corporate espionage and suchlike.

by song 11y ago

ild 11y ago

> it's considered lower level to be a software engineer than to be a mechanical or electrical engineer, so the smartest kids do not study computer science (this might have changed since). Which is very interesting, because in US it is completely opposite (and frankly it is not good either). Is it because US deindustrialized itself last 40 years?

thrownaway2424 11y ago
Did you mean "Deindustrialization or deindustrialisation is a process of social and economic change caused by the removal or reduction of industrial capacity or activity in a country or region, especially heavy industry or manufacturing industry." ? That doesn't sound applicable to the USA, which currently produces more goods than ever before, and more than any other nation except China.
- peterfirefly 11y ago
  It does so with far fewer people than before, though. In that sense, there has been a "deindustrialization".
- ild 11y ago
  I am talking about industry as share of GDP. Check the numbers: http://en.wikipedia.org/wiki/Economy_of_the_United_States_by_sector http://en.wikipedia.org/wiki/Economy_of_the_United_States_by.... Manufacturing kept going down.
SiVal 11y ago
It was not the opposite in the US 30 years ago, when I chose EE over CS, because EE was clearly more respected as being the more intellectually demanding. This had a lot to do with the capabilities of hardware at the time and the locus of value. IBM sold its hardware for millions. It gave away the software. The hardware was the differentiator; software was generic. EEs who could improve the expensive hardware were a lot more valuable than programmers who could improve the free software. In fact, since doubling a hardware resource such as RAM far more than doubles what you can then build with software, the hardware guys were more important than the software guys--even to the software. As hardware limits were relaxed over the years, what you could accomplish in software, even with cheap hardware, grew so enormously that the primary value was increasingly in the software. This was such a rapid transition in the computer industry that it nearly destroyed IBM, it propelled Microsoft to power, and I ended up with a career in software. Toyota and other Asian "hardware" vendors are in some sense where IBM was. They sell prize-winning hardware and whatever software that comes with it is essentially free. (Apple is a lot like this, which is why their hardware keeps getting better and their software--well, did I mention the hardware is thinner?) The Toyota "platform" still can't do much in software, but it's growing exponentially. Eventually the software in a car might matter more than the (commodity?) hardware, but that's not the world in which Toyota managers were formed. They are obsessive about hardware, but software is an afterthought. It's for guys who couldn't cut it as "real engineers", as was the case in the American "computer industry" until the 1980s. I also lived and worked in Japan. I was a strategy consultant, and I was told by some big Japanese and Korean companies (whom everyone has heard of) to emphasize my hardware background and not be seen spending too much time hanging out with the software guys if I valued my reputation.
- mirsadm 11y ago
  Apple is not like that at all. Their software is excellent. My guess is that a large percentage of their customers keep buying their hardware because of iOS or OS X not because it's thinner.

rdtsc 11y ago

There was an article about this (in New Yorker, I think...) a few years back, t how Japan has this strange relationship with software. How it is a hardware-first country. Many reasons were given -- cultural, how "real men build real things", infatuation with appliances, which are seen as being "hardware" in a way, perhaps the langauge barrier i.e. existing software tools using English for menus and inputs etc. And it is kind of interesting, looking back at a country that many in the 80's feared with surpass and leave the Western world in the dust technology-wise, we haven't seen that much software produced there. Can you think of large well known software from Japan (excluding console games). Vine Linux, SoftEther VPN, TrendMicro, anything else? One wonders if they see Western software companies and if there is any desire to catch up or try to keep up. Maybe anyone from Japan can provide a better perspective?

karpodiem 11y ago
let me know if you can find that New Yorker article, I'd be interested in reading it.
- rdtsc 11y ago
  I think I found it http://www.economist.com/node/18958643 http://www.economist.com/node/18958643 it looks like it was in the Economist not New Yorker
  - karpodiem 11y ago
    thanks!
cma 11y ago
Why exclude console games?
- rdtsc 11y ago
  I guess I see it as part of the appliance. Not something you download and install or use an API to access.

awongh 11y ago

This is also an interesting contrast to the (I assume higher quality) kind of work being put out by their other engineering departments- how can they make other sound engineering decisions on the rest of the car and it's manufacture, but fail at the software? Is it something specific to software vs. traditional engineering in Japanese culture, or is it something inherent to software in general? Given the parent's complaints about workplace culture in general, shouldn't the entire car be badly designed?

hliyan 11y ago
Exactly why I'm commenting so much on this. I always tell my team "Pay attention to detail, quality, method. Be more like the Japanese", to now see that even the Japanese (and their quality poster-boy no less) have trouble applying their quality philosophy to software. Not sure where that leaves my advice.
- thaumaturgy 11y ago
  It doesn't change your advice. Toyota has a well-deserved reputation for quality in a lot of areas: customer service (they've been replacing frames on trucks for a few years at no cost to the consumer), construction, reliability, maintainability. That they have flaws in one area just means that they need to apply their practices to that area too.
lifekaizen 11y ago
I worked in new auto development at Toyota (Japan) for four years in mid 2000s, right before this happened. The unintended acceleration problem has also perplexed me, because in my experience any safety issue was always given top priority. But I did experience limited familiarity with software/firmware. Usually that was looked at as part of the component, for example the engine control module in it's physical plastic housing. Remember the production auto will have Denso (or similar) delivering that ECU to the factory as an "assembly" and hundreds or thousands of these are assembled into the car and function together. At the end of the assembly line, various tests are run on the system and vehicle, but these appear to be of the "input/output" that someone else described. So why isn't software done better? I'd say one problem is the testing process is not robust enough for software/firmware as it is for mechanicals. The tests revolve around driving the car, and variations on driving, and have evolved over years and decades. Heavy software control is newer, and in my experience was often not fully understood. Chief Engineers tend to come from mechanical. And there are always hundreds of problems to solve and limited time, and the black-box nature of firmware makes it hard to develop tests for. A development review meeting tends include various mechanical departments, like Drivetrain or Engine or Chassis, many times they bring physical prototypes to the meeting and the problems and proposed solutions are comprehensible. The build testing procedures subject the car/parts to various mechanical tests, and long-lead tests are performed which stress parts till breaking. It's something you develop experience with an can get your head around. Firmware bugs are not like that -- having just gone through this with my current consumer electronics startup I experienced the black box component first hand. I remember one software based problem we reviewed at Toyota, where something happened like: when the car has been sitting for >3 hours at <50F weather, and the ignition is started when the car is at a 15 degree angle (side of road) and driven on to a flat plane within 15 seconds, the "check engine" light turns on. Even though we had no test for that, we heard about it for customer complaints came through. But the fix is to have the supplier (in this case, but could be the Toyota engineer) fix that problem, with most of the discussion centered on timing and certainty of fix. I don't remember any discussions about global variables or lines of code.

abawany 11y ago

I can state that this matched my experience though I was in the US - this was in the 90s, and in the automotive industry. I used to work at Motorola Automotive and Industrial and our team built the Computer-Aided Manufacturing systems that managed the production lines. It always felt like a tier-2 job compared to process engineering.

enupten 11y ago

This is a genuine question: why can't they outsource their software devel ?

Cthulhu_ 11y ago
Given how they had the researcher effectively locked up in a hotel room with strict security measures, I'd say it's because they're terrified of corporate espionage and suchlike.