Translating Object Design

Recently I received a copy of the Chinese translation of my book, Object Design: Roles, Responsibilties and Collaborations. It took nearly three years to translate. I hope it sells well, although authors only get a mere pittance for selling translation rights (think $100 or less--and I have to split that with my co-author). So I won’t be making money even if becines a best seller in China. Creating and marketing a best selling book can be dicey as this interesting blog posting for someone in the book publishing business points out (I didn’t write this book to retire on, I wrote it to get the word out about role-based object design).


I found it fascinating to compare the English with the Chinese edition. As I thumbed through the book several features were missing that we thought essential when we originally worked with our editor (in hindsight, our requests added to the book’s cost, but probably made little difference in how well it has sold). We convinced our editor to produce a two-color book so we could annotate drawings using blue. The editors then figured out ways to incorporate blue into subsection titles, boxed in examples, etc. The Chinese edition was black and white and had no index. Margin comments had been boxed off and inserted along with the main text. That certainly made formatting a lot easier.

It was interesting to see the text sprinkled with English words and pseudo-English class names: e.g. Rebecca Wirfs-Brock, Brian Wilkerson, “Rational Unified Process”, Kay, GuessingLettersOnly, aMessageBuilder,–Michael Jackson (the UK problem frames inventor, not THE singer). The format of the Chinese edition numbered subsections, where in the English language version we did not. On the cover, our names were in a smaller font than the text, “forewards by Ivar Jacobson and John Vlissides.” I’m guessing this was to sell more books. The cover included the same cover art but the lettering and colors were much simpler. On the cover, the book’s title was in both Chinese and English. The paper is thin decreasing the thickness of the book by 50%. Printing quality wasn’t great. The translated book was 313 pages vs. 390 for the English version. I wonder whether Chinese writing is more compact or whether parts have been omitted. It is hard to tell.

I’m meeting with one of the translators of our book to Japanese at next week's Architecture and Design World. I really look forward to meeting him in person. Translators who take their job seriously ponder words and meanings. And because of the differences of words in different languages, they can uncover nuances than I ever thought about. For example, I received this query from the Japanese translator about this sentence from our book, “As we conceive our design, we must constantly consider each object’s value to its immediate neighborhood.” He asked, "Does the meaning of neighborhood in your book correspond to the definition 'objects who live near one another' or 'in a particular district or area'? If your answer is yes, could you make selection between 'live near one another' or 'in a particular district or area' because we have different Japanese words for each.”

One of my favorite books is Douglas Hofstadter’s Le Ton Beau De Marot: In Praise of the Music of Language. This book is all about the nuances of translation. Hofstadter, who also wrote the best-selling Gödel, Escher, Bach: An Eternal Golden Braid, explores the myriad constraints that must be chosen to be relaxed (or tightened) when translating, as well as the choices the translator makes to preserve the original author's context or to translate it to a more familiar one of the reader. As a vehicle to explore these ideas, he used a 500 year old French poem that he gave to many friends and colleagues to translate (and he, himself wrote dozens of translations). It’s fascinating reading. As a designer and requirements analyst, I often find myself discriminating very fine shades of meaning. There’s nothing straightforward or mechanical about this process. But to me, translating poetry seems much more challenging . And translators of technical books deserve credit and recognition for their own contributions.

Pay by the job, or pay as you go?

I was intrigued by the promotion, “we charge by the job…not the hour” (and I admit the kitchen magnet advertisement glued to my phone book cover caught my eye). Even though I had been thoroughly satisfied with my previous plumbers who had a pay-as-you-go model, I was intrigued with this seemingly more informed, one price upfront approach. Who wants to get into a job and find out that the cost will be five times what you expected? So I called up this plumbing company and made an appointment to repair my split hose on my instant hot machine and my fridge’s ice maker.

Within two minutes of the plumber arriving, I knew I had made a mistake. The plumber charged 48.50 USD to just show up. (That was OK as I had been apprised of that policy when I scheduled the appointment). But after shining his flashlight under the sink for a couple of seconds, the plumber delivered this instant analysis: “We don’t repair instant hot units. We don’t carry parts to do repairs on appliances as there are so many brands and models. Yes, I can see that the hose is split (I had already made that diagnosis and had told them that when scheduling my appointment). The best I can offer you is a new instant hot unit installed for $695 plus $40 extra assembly fee because you have other appliances under the sink that are in the way that I’ll have to work around.” He continued, “Since we don’t repair appliances, if your fridge ice maker stopped working all of a sudden and there is no dripping water from a broken line, all I can do is charge you a $90 discovery fee to pull your fridge out from the wall and inspect the plumbing connection. Perhaps there’s a kink in the line. But if I don’t find anything, I can’t do any more as I can’t see where the line goes from the sink to the fridge. ” Hm, so how could he troubleshoot the plumbing from under the sink to the fridge? He wasn’t even offering me an end-to-end diagnosis.

I was extremely frustrated by his seemingly flawed diagnosis proposal and big-ticket component replacement offer. Pay as you go had seemed good in theory—but in practice it seemed a sham. The plumber quoted big repair $$ when I wanted confidence of a reasoned approach. Why couldn’t he repair a simple hose? What use was a quick look behind the fridge? It’s not like I had moved my built-in fridge since it was installed 7 years ago. He hadn’t even checked whether the water line was on (It was on. I had fiddled with it before he arrived, just to make sure).

This plumber wasn’t willing or equipped to do the little things that would maximize my satisfaction and minimize cost. He wouldn’t make minor repairs. And big ticket items or obvious diagnoses seemed all he had to offer. I paid $48.50 and sent him on his way.

I explored how repair my instant hot hose with handier friends and family, and then repaired it by installing a clamp purchased for $0.79 at The Home Depot. I plan on calling the fridge repairman because he’ll be able to perform an end-to-end diagnosis and can repair my fridge if that’s where the problem lies. Next time I’ll make sure the plumber can work by the hour and is willing to troubleshoot by the hour and make minor repairs.

What’s this story have to do with software? Well consider how you decide to get pay for software to be repaired, extended, or upgraded. At a first blush, a fixed bid contract might seem reasonable (or a fixed time estimate from your development team). But “quote one price for the whole shebang” arrangements can lead to padded numbers and the inability for creative wiggle room for making quick fixes or simpler solutions. On the other hand, with time-and-materials projects, you can ask upfront, “Well, how long does it take you to do a typical project like mine?” A developer might reasonably be expected to give a ballpark estimate based on prior experiences (and can tell you how glitches will be communicated and worked through). And if the team is following an agile approach, they'll deliver working software in small increments, keeping visible records of how long tasks take vs. initially estimated. If it turns out that a job is simpler or more complex than expected, with a pay-as-you-go approach, a customer get deeply involved in decision-making and can renegotiate priorities. Sure, there’s a risk ofpaying lots of money for junk or, even worse, unfinished software. But with frequent, open communications, problems can be spotted and approaches mutually agreed upon before laying out a big investment.