At the small Japanese company where I worked there was a pretty stiff resistance to using full-blown web frameworks. The main argument was that it would take too much time to train people to use the framework, and that open-source frameworks were somehow unreliable. So they ended up poorly re-inventing several wheels (like using plain text files and locking for storing data, or a crude templating system) without first checking out the available open-source alternatives. It often felt like we were working at the wrong level of abstraction. On a more practical note, most of our clients used shared hosting with such draconian limitations and ancient server software that it would have been pretty difficult to use some of the modern frameworks even if we'd wanted to. (Think servers with PHP 4 and FTP access only.) I don't think everywhere is as bad as that was, but in my experience not-invented-here syndrome seems to be pretty common here in Japan.
I had to have the president of the company call them and get them to move us to a server with PHP5. This was 2.5 years ago - well after when PHP4 was deadended.
Regardless, setting PHP4 as the default in 2009 is idiotic.
I remember when the PS3 was first shown at E3 many years ago, one of the big selling points that Sony was advertising was how difficult it was to program for it. They happily extolled the fact that it would be a 10 year platform because that's how long it would take programmers to learn how to program for it.
Meanwhile, some big 3D devs like John Carmack were talking about how nice it was to develop for the XBox 360 because everything felt so familiar and MS already had a mature toolset available for people to use.
I don't know if this dichotomy is a reflection of the blog post or more a reflection of the games industry at that time.
I'm pretty surprised to hear that, as we have always been working hard to make the SDK easier for game devs.
Do you remember who said that?
Also, while I agree that there are lots of competent coders, engineers just aren't as ruthless about personal productivity. They'd rather not rock the boat instead of getting into an argument. There's also the social tendency to take any form of argument personally. Combined with age-based seniority in programming teams, this kills innovation quick. A younger engineer with a pulse on the latest cutting edge technology isn't going to be heard at all. A crusty veteran, will just overrule them and say, "follow tradition". After decades of soul-crushing guess what these once brilliant engineers will say to fresh meat?
It would take a lot of courage for a younger, capable engineer to go and rewrite the code of a senior engineer even if it's mediocre, he'd have to be careful even in wording the commit message. Performance on the job is not rewarded as much as "competence (meaning just enough to get by but not so much as to make others look stupid)" and at most you'll rarely get promoted over older employees, you'll just be first among equals in your age group and so will your salary (almost negligible in terms of monetary differentiation, people will just treat you better because you're on the "fast" track). If your body and mental health manages to survive the hours you might get rewarded in a management position by your 40s and join the ranks of "young guns" where you get to try your luck in Japanese corporate politics where deals are cut in dirty drinking shacks over yakitori and beer.
Breakdown of academic background for elite companies:
I worked for a large Japanese hardware company many years ago. They had an entire floor full of programmers (YES, not kidding!!!) who were working on a new software product and when the first beta versions started to surface our guys in Europe saw how bad and hopeless it was. So they assembled a small competing team of 3 guys in Europe (I did the software design and coding – it was actually my first real job!). The headquarters provided all the necessary documentation and 1 year later we had a working product finished before them!!
I think one of the major problem was that they had incompetent managers and nobody questioned their authority/ideas. Everyone did what they were told! No independent thinking! Seems like a cultural thing to me.
I think the reason this happens is because people are rewarded differently. For example, if there's a crunch session and you manage to solve your bit of the problem with a fancy algorithm that means you get to go home early, while all the others work the 'less smart' way and spend overtime in the company, then the company will look favorably on those who worked longer, not those who worked in less time.
Since the culture expects you to work overtime anyway some people will believe that there's no point in working smart but less, since you'll only be working smart but the equal amount of hours anyway if you want to be respected. I've seen plenty of my colleagues following this routine and I've seen some foreigners fall for this trap too. It's a kind of culture that does not reward change.
As for me, I couldn't care less about how people perceived me so I just went on designing things the 'right' way (and going home in time for dinner). It worked out very well for me, but I doubt that a Japanese person could pull it off as easily, since they have to worry about their reputation a lot more than foreigners.
This showed the amount of dedication and respect to Japanese market and companies (many of which invested heavily in Java, I know), but I understand how it can go both ways:
When some programming languages and tools are translated to your language and some aren't, you might become stuck with those which are, and they are perhaps older, limited and less experimental. Limiting your toolset based on the human language is surely a problem. When you have to use tool A and not B and C because B and C aren't and won't be translated to your language (and then you have peer and management pressure).
I also remember a few years ago on NH a comment by Dutch developer who claimed that very few books about software development tools are published in Dutch, so they use original English sources and whatever tools are good, but when they come to Germany they see full bookshelves on programming topics in German - so people are reading those instead of original docs and limit their toolset.
But there is another thing, maybe Japanese see programming as Engineering. A respected craft, but you don't reuse much of electrical engineering output between projects, neither expect youe engineers to take care of the product side of the product. They usually do what they are told or don't when it's too expensive or would not work that way.
Programmers are pretty distinct: they can reuse, they have to face the product side and they're much less constrained by a physical media so they can go a long way towards a wrong path.
Which would probably make Japanese system programming thrive but Japanese customer- or developer-faced software suffer.
Quite the opposite, programming is seen as a grunt work which anyone can do by many of companies.
To put it in perspective programming jobs go from around $30,000 to $50,000 per annum depending on experience. That's not a typo (American dollars). Any programmer making more than $100,000 at a Japanese company is either one of the founders and/or sitting on the board.
Btw, if anyone is wondering, I am not a native english speaker. But I did learn how to program by reading the books and documentation that were available in english. If I had waited for somebody to translate these to my language, I probably wouldn't know a thing about programming to this day.
Once I told the management to have them learn English because it's almost mandatory for a software engineer to understand English as much as an aspiring Go player would learn Japanese. But the management told me back it's _harsh_ to require them to learn anything more. Harsh? Huh?
That said, I found the need for technical books real, and translated several English books (including Programming Erlang) into Japanese. However I know this effort will not scale and these days I am inclined to abandon translation and tell them that English is just another tool you have to learn to survive.
But you are right that within the Indo-European language family English does not seem to be one of the more complicated languages. Which might have something to do with its origins as a pidgin of French, Anglo-Saxon, Frisian and Danish.
When I spoke to the management about this, they said that they were in a position where they couldn't say no to Docomo and likewise they didn't see anyway of not continuing to do their development. And yet, and no offense to the folks grinding this stuff out, there was little real differentiation in the software, the OEM's were all focusing on the hardware feature differentiation and the software was really just a "necessary evil."
So I'm not convinced that it's simply a case of needing a "force multiplier" framework, the Japanese companies need to see that there's value in cultivating better, highly differentiated software.
DeNA, GREE, and the other Japanese social startups seem to have found this whereas the larger vertically integrated semi manufacturers are basically stuck writing drivers for their whizzbang hardware.
"my team wrote x KLOC of code and implemented k features...blah blah blah"
It was more than 10 years ago when I joined Fujitsu's 3G cellular network project as a subcontractor. It was a huge complex project and I believe was one of the first 3G networks deployed in the world. So I expected I would work with teams of descent engineers.
Except most of them were not.
The subproject had dozens of 'engineers', but many of them had just finished vocational schools that didn't teach them even programming in C. To make it worse, the existing code base was the exemplar of bad code, e.g. each function had more than 3000 lines, function names were a letter and some digits and we had to consult some other documents to find out what they were expected to do, etc as well as more architectural design problems. In fact there I was able to find every horror story about software development.
Why did such a mess happen? One of the reasons was that the contractor company (who then outsourced some senior positions to subcontractors like me) were paid by the headcount of engineers it offered to the project. No kidding. So, in order to maximize the profit, the contractor made up a legion of those incapables who were paid less. Expectedly that made things worse, and Fujitsu thought it needed more engineers to solve the problems. Vicious circle.
I had tried to make the situation better, but the root cause was not in the technical side and I had no clue. The only nice thing for me was that during the personal research to improve the project I got to know Erlang, which was of course never ever used in the project because of the similar reasons mentioned in the article.
I can confirm from limited experience that this is happening. But the problem is that “giving Japanese programmers good frameworks and libraries” is not as easy as just handing them a package and being done with it. The pace of modern frameworks like Rails etc. is so fast that there is a big learning curve just getting used to staying in the loop.
We lost at least a week on a project I’m working on catching up when Rails 3.1 hit, because all these useful things (asset pipeline, etc.) require effort to tie into existing practices. Imagine the Japanese developer with limited English skill, trying to navigate the discussion threads like this one ( https://github.com/chriseppstein/compass/issues/337 ) (just as an example). It’s a lot of work.
So I think what happens is that, although re-inventing the wheel is a hell of a job, at least it means that the basic groundwork is constant and designed internally, whereas using frameworks means that you’re building on someone else’s work — usually non-Japanese, so not well documented in Japanese.
The biggest difference between myself and a Japanese programmer is that if I run into a problem I can jump on to Google and find huge amounts of English information (docs, forums, stackoverflow etc.) to help me solve it.
Japanese programmers who are not pretty damn fluent in English cannot do this and this really is a brick wall.
I haven't seen much NIH syndrome, mainly it is because they cannot effectively search the net libraries / apps that they can use; again due to the language barrier.
So in the end they make their own.
Plus to dive into the code you have to have a reasonable idea where to start to look for your problem which can also be a barrier in a complicated project where the comments / guides / documentation is in English.
Just makes their jobs that much harder.
Westerners, who may have started programming out of personal interest, may simply spend more time after work building up social communities to solve problems they have at work.
In Japan programming may simply be viewed more as "a salary job" they could qualify for, filled with lots of uninspired folks who just want to grind through their shift and get the hell out of there at the end of the day.
At least that's how my friends who've worked in both Japanese and Western companies describe the situation.
Um, have you ever been to the US? It's like that here too.
I am from Austria and we need to do lots of coursework in English in economics because all the literature is English and you can't work in the profession without a good command of the language.
I hear the weeaboos across the world now screaming “what about Ruby!”, but Ruby just proves the point. A Mormon Japanese dude (read: English literate, world-focused, non-Otaku, non-loner mindset) coupled with an excellent framework that gained fame world-wide (Rails). It’s nice that there are great Japanese Rubyists but they are not responsible for the popularity of the language.
The Japanese in question is this guy: http://en.wikipedia.org/wiki/Yukihiro_Matsumoto .
With all the Ruby enthusiasts outside of Japan, it seems unnatural that most of the core commiters are still Japanese.
A few years ago Cookpad (http://cookpad.com/), a Japanese recipe site with millions of users, switched to Rails. That may be contributing to a change in awareness locally.
The people I was referring to were people are the ones who believe everything needs to be built close to the metal, and that scripting languages are toys that cannot be used for serious engineering. They are generally older, in positions of management, and useless.
> "what about Ruby!"
Ideally, you would probably want the Japanese programmers using the exact same frameworks as the rest of the world- reinventing Python in Japanese would boil down to duplicated and thus most likely wasted effort.
Lots of focus on certificates and standards and consensus and other proof of 'merit', and not a lot of focus on getting shit done and programming, motherfucker.