Over the past year or two, proponents of the Java programming language have made tremendous strides in breaking down barriers and establishing a strong foothold for the language in the Japanese marketplace. The FUD (fear, uncertainty, doubt) factor has subsided considerably, and even the largest and most conservative Japanese companies are now openly embracing Java-based products and services. In this and other upcoming articles, Computing Japan will be spotlighting Java-based projects undertaken either in-house or by major Japanese corporations and organizations, with the hope of shedding light on both the nature of Java use in Japan and the overall craziness of custom software development projects in general.

As its name implies, THETA (tonal Harmony Exploration and Tutorial Assistant) is a music editing program that allows users to easily experiment with different melodies and harmonies. Developed in Java by Linc Media, Computing Japan's parent company, the program is accessible directly from the Web - users do not have to download or install any additional software. A key feature of the system is that users are able to save their work in either a private folder that only they can view or in a publicly accessible repository. This way, musicians can easily share notated melodies or experiment with changing the harmonies or instrumentation on other users' compositions. The music can also be played back in real-time over the Web.

The system comprises a Java applet/ servlet combination, which hooks into a MySQL database on the back end. All of the code for handling the user interface aspects of the music editor are placed in the applet, while the servlet is responsible for converting the score representation into a binary MIDI file and sending back the HTML that points to the file every time the "play" button is pressed. The servlet also handles all communication with the database, such as the storage and retrieval of compositions.

THETA was intended primarily for use as an educational software tool. Musicians tend to learn most effectively by listening to and studying the work of other musicians. Jazz and blues players often get together and "trade licks," whereby one player takes a melodic phrase or fragment from another player and twists it around to fit his own style, maybe using it in different contexts and keys. In much the same way that open source software development projects now give budding programmers the chance to cut their teeth on code written by experienced developers, THETA is meant to foster the same type of source-sharing among musicians, giving students the freedom to study, edit, and expand upon the work of others.

Brau greeting card project

Eventually, it became evident that in addition to its potential uses as an educational tool, THETA might have other commercial uses as well. In the latter part of 1998, Linc was approached by NTT-X, a subsidiary of NTT that focuses on Web- and multimedia-based projects. NTT-X was in the process of building a greeting card website to support the launch of Sapporo's new Brau label and was looking for something a little out of the ordinary to distinguish the site from its Japanese competitors. Our contact at NTT had seen the THETA demo prototype and proposed that we alter it for use on the greeting card site, allowing users to compose their own theme or song for inclusion in the card. When someone receives one of these cards, he or she clicks on a link that displays the card as a Web page and starts playing the song. While other greeting card sites at the time offered users the option of choosing from canned melodies to put in their cards, nobody else had given users the chance to compose original music to put in the greeting.

Much of the work for this project centered around the creation of an intuitive Japanese-language interface for the editor. All instructions were in English, the interface was difficult to use, and, as we would discover in the coming weeks, the code was crawling with bugs. From the start, NTT insisted that the program must work on Windows IE 4+ and Netscape 4+. Up to that point, however, the system had been tested almost exclusively on Netscape, and several hacks were necessary to get the components working equally well on IE. They also wanted a standard menu bar interface for selecting chords and instruments, a larger editing window that contained four staves instead of one, and a "save" button in place of the "text input" button.

To handle the language aspect of Japanese localization, we decided to create tables for each language version of THETA. When the applet initializes, it simply reads in the language as a parameter, then loads the appropriate language table. For example, all of the English table entries contained the same string for both the key and value: "Open, Open"; "Save, Save"; and so forth. Inside the applet, strings are never hardcoded, but are instead referenced via the language table. By isolating all of the language-specific issues in separate tables, we were able to create a multilingual system that uses a single code base, and now do not have to worry about maintaining and synchronizing different language versions of the applet.

After delivering a user interface prototype, NTT came back with a slightly unexpected change request. It seemed that none of the prototype testers were able to understand the "eraser" image button. It was not simply that they didn't understand the function of the button; they couldn't even determine what the image was supposed to represent, because virtually all pencils used in Japan are of the mechanical variety. The pencil tip eraser so instantly familiar to North Americans is essentially unknown here. We were subsequently asked to come up with a more keshigomu-rashii (eraser-like) image. Likewise, we were told that a large number of people also had a hard time associating the image of a speaker with the playback function. These examples underscored once again two highly important points:

(1) localization is very distinct from internationalization; and

(2) there is much more to both localization and internationalization than just language and locale issues.

THETA Beta

Once we were set on how the interface should look, we proceeded to the design phase and then on to development. Initial implementation was finished pretty much according to schedule, allowing for a two-week beta testing period. During the first part of the beta period, numerous bugs were found: alignment was slightly off for some keys, the eraser didn't work sometimes, some notes didn't play properly if they were sharped, and so on.

On one occasion, an NTT beta tester input a melody that, to me, looked for all the world like a string of random notes. When he hit the "play" button, nothing happened. A bit taken aback, I tried altering the melody a bit and found that by changing any part of it, the problem was fixed and the sequence played back properly. "Could be that there's just something odd about that one particular sequence of notes," I said hopefully. "Since it doesn't seem very likely that a user would randomly lay down that same exact sequence of notes, we probably shouldn't worry about it too much." "Well, actually, that is a very famous Japanese folk song," he replied. The bug got fixed that day.

Not surprisingly, clients and developers tend to have totally different perspectives when it comes to bug fixes and expectations. In fact, I am often reminded of the scene in Annie Hall where Woody Allen and Annie are each asked by their psychiatrist on separate occasions how many times a week they have sex:

Account Exec: So how many bugs do we have left to fix on this software?

Programmer (dismissively): Hardly any ... maybe three.

Client (angrily): Way too many ... jeez, there must be at least three!

It is not that the programmer feels that the bugs are unimportant; on the contrary, he or she is usually very bothered by them too, and has every intention of getting them fixed. The discrepancy lies in the fact that the programmer knows all too well that by today's standards, for a large software project where the tiniest miscalculation on any part of the program can trigger countless errors, having only three known bugs going into beta is a pretty phenomenal achievement. In the future, building software may become as well-understood and routine as manufacturing toilet seats, but today we are still light years away from that level of standardization. The client, however, just knows that something is not working the way she expected it to, and quite understandably wants the problem fixed. So who's right? It really doesn't matter. If the programmer wants to stay in the custom development business, he bites his lip and fixes the bugs.

That is not to say that all bugs can be found (much less fixed) by sheer effort alone. In fact, as anyone who has ever coded anything knows, software bugs are notoriously adept at escaping detection until the precise moment that you decide to ship, launch, publicize, or demo. Testing and quality control are just two more areas where there exist vast differences of opinion between those who write software for a living and those who buy or sell software for a living, but that is a whole separate issue. Coming back to the Brau project log, we had a period of six days during which no problems were reported by either side. Then, two days before the launch, just when it appeared that everything was finally stable, I received the following e-mail:

Dear Steven,

We are very tired because we found so many bugs in the THETA program. We do not want to lose our customer, so we hope that you will please find and fix these bugs. We expect and appreciate your good job.

Now adjusting for Japanese politeness levels, this actually translates a little more accurately into American vernacular as:

You Idiot Programmer,

We are getting pretty fed up with constantly finding bugs in this software that YOU should have already found and taken care of yourself. Why are you so damn negligent in your testing? We are sick and tired of doing your work for you. Get this fixed immediately or you will not be getting paid.

As we went about fixing the problems they had listed, I realized that we had made a classic blunder by testing only the 'ordinary' situations and didn't really consider the many cases when users do something unexpected. The folks at NTT, on the other hand, spent hours just hammering at the program, trying combinations of chords and notes that would probably never occur in an actual composition but are nonetheless legal and must work as expected. Most of these "final-stage" problems occurred on such "odd combinations," and the bugs had probably been there for the past year, managing to avoid discovery because most of the tests were being done on actual songs.

Nevertheless, we managed to fix the final bugs, and NTT was able to launch the site on schedule. The Brau Greeting Card Site has now been in operation since last February 8, and over 5,000 people have sent cards with their own songs attached. Although we were aware that the general music literacy rate was much higher in Japan than in many other countries, almost everyone involved was still a little surprised at the number of people using THETA to put original music into cards.

Finally, the engineers and managers at NTT were extremely professional throughout the entire project and a total pleasure to work with. Fortunately, they were very knowledgeable about the nature of software development and never made any unreasonable demands or requests. Best of all, they even sent us an otsukare-sama (big thank you) case of Brau at the end of the project!

THETA today and beyond

While NTT-X continues to license the software for use on the Brau site, Linc has since opened up THETA to the public. Currently, anyone may register to receive an account free of charge and can create an unlimited number of compositions. Initially, users were allowed to post their compositions directly to the public repository, but it soon became evident that some kind of evaluation and filtering system was necessary, as the repository began filling up with dinky three-note fragments that had been given titles like "Erotica!" and "SEXY DANCE." Submissions are now evaluated by a Linc employee before being placed in the repository.

At present, Linc is exploring the possibility of including the applet portion of the system as part of an educational software CD-ROM package that would be distributed to private schools throughout Japan. Also in the works is an Australia Web theme-writing contest, complete with native Australian instruments, open to users of the Australian Embassy website. Finally, the next full upgrade of the software, set for release in fall 1999, will include ear-training exercises and games that track the progress of each student; extensions to the editor to allow for triplets, ties, and slurs; and more chords and voicings.