DoCoMo D800iDS - Direct and Smooth

With all the hype about the iPhone and a delayed release in Japan I was counting the days before I saw some of it rub off here in Japan. I didn't have to count too many days, since the D800iDS was announced by DoCoMo.

There have been a few other handsets with completely virtual stylus-free UI's in Japan. I recently worked with a guy that had an old mono-lcd KDDI handset with no mechanical controls except a manner-mode button on the side. I was especially interested in the D800iDS because I have come to love the design of the Mitsubishi 900i series. Slim sliders with huge screens and lots of extra features. KDDI seems to think it's pretty cool, too. Two AU handsets by Toshiba (W52t) and Sanyo (W51SA) coming out this spring look quite similar to it.

Anyway, the D800iDS looks pretty cool, if not a little prototypish. I wonder if it is just a coincidence that it came out on the iPhone's heels. Probably not. At first I thought the DS stood for "Dual Screen", but apparently it stands for "Direct and Smooth". The keypad area is a touch screen where contextual menus are displayed. Keypad and phone menu icons are displayed depending on what application you are using. There is a drawing program and handwriting recognition (similar to that found on the AU W42SA). There is also "Two-Touch" kana entry, as the contextual keys change when you select a kana to enter. This would be cool, since entering "se" (せ) for example takes at least 3 or 4 key presses.

I should be receiving one of these at work soon, so maybe I'll have more to say about it later.

Back in Tokyo, for now

So I'm back in Tokyo this week since Monday. Some changes at work may mean I will move to Amsterdam to help expand the business there. I'm pretty excited about the prospect of living in Europe and occasionally visiting Japan once a quarter or so. Japan is a great place to visit, but living in Tokyo is another matter altogether. Especially if you work 12 hours a day and are expected to work weekends if there are any problems.

I chatted with a coworker in Europe about quality of life versus work performance in The Netherlands and Japan. In Japan, long hours imply productivity regardless of what you are doing. This is definitely true for a lot of my Japanese coworkers. In The Netherlands, if you often work late, you might be seen as inefficient or poor at delegating. HR might come around to ask you what your problem is.

I think working in NL will allow me more of a life outside of work without instigating questions about why I leave work before the CTO does. Plus going to other countries can be a weekend trip rather than a big ordeal. Also, I hear Mobile Monday is starting up in Amsterdam, so I could still do some networking without a train ticket or rental car.

Maybe soon I will have to change my subtitle to "Working on the mobile web in Amsterdam". Fingers crossed...

Going To London Next Week

Can't sleep, so might as well mention that I am going to London next week for a few days to visit a potential client. I really enjoy going to Europe, even if for a short business trip. I have started pulling some strings to get relocated to The Netherlands. I think I would enjoy a break from Japan for a while.

Software Quality: Japanese and Foreign Perspectives

*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:

1. It's a Japanese company.
2. The development team is from all over the world. Finnish, Japanese, American, Canadian, German, Danish, Australian, and Filipino.
3. 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.

Meeting Marathon Hell

I was really hoping to go to the Mobile Monday Bonenkai yesterday. Unfortunately I was in mind-numbing meetings until 23:00. I could not believe it. Why, why can we not end a meeting quickly and gracefully? There is the tendency to digress into completely separate topics for no apparent reason. Maybe I just don't see the connection sometimes. Anyway, I hope Monday's become a little more reasonable so I can make it to Mobile Monday more often. We should all go!