*This is just an observation based on my limited experience working with foreign and Japanese software engineers.
A coworker blogged this article a couple of weeks ago. It's all Japanese, much of it in images, but using an online translator will give you the general idea. It portrays the "real" feelings Japanese and foreign tech workers have about each other. Much of it I agree with. One statement made by a Japanese consultant about foreign engineers was especially relevant to a conflict I am experiencing at work.
But first, a little background:
- It's a Japanese company.
- The development team is from all over the world. Finnish, Japanese, American, Canadian, German, Danish, Australian, and Filipino.
- The QA team is all Japanese with the exception of a developer I lent to them for support.
The product we are working on is essentially a CMS for mobile web services. It was originally created for the European market. It was reasonably successful, so we decided that we would try it in the Japanese market as well. So far so good. We checked out the competition, consulted with prospects and soon after we started launching on and off-portal services in Japan.
Now the product in question was a bit of a departure from the company's usual way of developing software solutions at the time. They were used to building services from the ground up, tailoring it to the specific needs of the customer. Extendability and reuse were not top priorities. The idea of an extensible platform where nearly every feature and improvement developed can be utilized by every customer and leveraged for any sales prospect is very attractive. Of course this has drawbacks as well if the sales team is not used to such an approach. It takes a little time for everyone to acclimate to a new business model.
During that time development has the difficult challenge of keeping the features reusable and not too specific to any one customer. This makes creating specs a little trickier. You are not just trying to satisfy the customer in question, but future customers as well. The feature must be flexible enough to be reused with as little additional development as possible. Couple that with the fact that many organizations looking for a mobile presence do not know what they want, specifically. You get a general idea and perhaps some wireframes of the service layout. Not unusual, but difficult when you are trying to keep things somewhat generic in their application.
Tight schedules, multiple projects in different markets, very specific demands from some clients; an agile approach to the development process is pretty much mandatory under these circumstances.
Anyway.
The quote in the article that got my attention mentioned that foreign and Japanese engineers have completely different views on software quality. Basically, it stated that foreigners expect bugs and accept debugging as part of the development process, while Japanese take measures to prevent bugs altogether.
This is definitely the case in my limited experience. I am often asked by the CEO and other directors what I am doing to produce "zero-bug" releases. I don't have a good answer for this. I feel that if you didn't find any bugs, you didn't look hard enough. To achieve this I believe you need complete specs (and the time to write them), an unchanging environment, and unchanging requirements. We have none of these, so I consider the persuit of "zero-bug" software under these conditions a, well, waste of time. I would rather focus on keeping the critical ones from being released than holding up a release for a mispelled word in the GUI. The all-Japanese QA team believes that they should not be able to find any bugs. That would be pretty cool, but come on. I think our QA process is not agile or adaptive enough. Finding bugs should not bring all testing to a halt. QA finding bugs should not be interpreted as a deficiency in the dev team. I think if the development environment requires agility, the other steps of the release must reflect this.
Is this a Japanese thing? All the foreign developers pretty much agree that bugs are a fact of life. Inability to cope with them skillfully means any mistake will interfere with the process, making planning or scheduling at any level impossible. Some of our larger competitors in Japan (with many more resources than we have) eventually come to us because after years of building custom solutions from scratch they have a huge, difficult to maintain collection of codebases. Even with shared libraries in use, thousands of PHP files in hundreds of projects require significant development resources just to maintain. Cost of operation starts to catch up with revenues and you need to find a better way to do it. Others take a more "product-like" approach and simply refuse to customize their software. More control over the feature set is offset by some missed opportunities due to a few missing features.
I get the feeling that Japanese customers are accustomed to asking for very specific, almost personalized functionality, expecting a solution to be developed just for them or significant changes to be made to an existing solution. In Japan, our most difficult projects are the ones where we port an existing service to our platform. There are always "features" so specific and narrowly defined they are difficult to recreate in an extensible way. This decreases their value to our product, and makes me wonder if our sales team needs to take some classes on managing customer expectations. There is a little more wiggle room with new services, since we can sometimes launch with an incomplete feature set and fill in the blanks in phases according to an agreed-upon schedule.
Is bug-free software a realistic goal? Only if specs are completely comprehensive and the requirements and environment are unchanging. Or if you have a lot of testers and a lot of time. Bug-free software is every developer's (and development manager's) dream, but the circumstances required for it sound pretty boring.
