Global Pragmatica LLC®

Erin Vang moderates panel discussion on software l10n

Cross-posted from Lingoport.com

So, you’ve developed a new software application, and have high aspirations in terms of selling your application to a global audience. Now what? Problems often arise between developers, localization managers, and business managers due to perceived lack of support, time, and money.

This lack of understanding can lead to great frustration within the development tiers. Join us for an hour long online panel discussion and learn how some of the best known industry thought leaders are contributing to bridging the gap between software development and localization.

The panel features the following industry thought leaders and experts from the software development, content development, internationalization, and localization industries:

• Val Swisher, Founder & CEO of Content Rules
• Danica Brinton, Senior Director of International at Zynga
• Dale Schultz, Globalization Test Architect at IBM
• Edwin Hoogerbeets, Senior Internationalization Engineer at Palm
• Adam Asnes, CEO & President of Lingoport

Online Panel Discussion: “Bridging the Gap Between Software Development and Localization”
Date and Times: Wednesday, August 3rd at 9:30am PT / 10:30am MT / 11:30am CT / 12:30pm ET
Registration: Register for free @ https://www1.gotomeeting.com/register/964415249
Where: Your desktop

Erin Vang, Owner of GlobalPragmatica will be facilitating the online panel discussion. Erin has over twenty years of expe­ri­ence in sta­tis­ti­cal soft­ware doc­u­men­ta­tion, qual­ity assur­ance, project man­age­ment, and local­iza­tion, most recently as Inter­na­tional Pro­gram Man­ager for the JMP Research and Devel­op­ment at SAS, and pre­vi­ously with Aba­cus Con­cepts and SYSTAT. She is currently designing a localization program for Dolby Laboratories.

This presentation is intended for technical managers, software engineers, test engineering managers, QA managers, internationalization and localization managers, technical writers, content developers, and anyone wanting to learn more on how to optimize their global software releases.

We’d love to hear from you. Please send any questions or topics you’d like to have discussed during this panel to Chris Raulf @ chris (at) lingoport.com.

Update 4 August 2011

The recording of our panel discussion is now available here.

Statisticians and data analysts are in a kerfuffle about the recent remarks of AnnMaria De Mars, Ph.D. (President of The Julia Group and a SAS Global Forum attendee) in her blog that the open source statistical analysis tool R is an “epic fail,” or to put it in Twitterese, #epicfail:

I know that R is free and I am actually a Unix fan and think Open Source software is a great idea. However, for me personally and for most users, both individual and organizational, the much greater cost of software is the time it takes to install it, maintain it, learn it and document it. On that, R is an epic fail.

And oh, how the hashtags and comments and teeth-gnashing began!

Nathan Yau’s excellent FlowingData blog recaps the kerfuffle nicely, and his post has accumulated a thoughtful comments thread, as has Dr. De Mars’, to both of which I added my thoughts, expanded here:

To make my prejudices clear, I’ve spent several decades in commercial statistical software development (working in a variety of R&D roles at SYSTAT, StatView, JMP, SAS, and Predictum, and I now do custom JMP scripting, etc., for Global Pragmatica LLC.

I can say with hard-won authority that:

– good statistical software development is difficult and expensive
– good quality assurance is more difficult and expensive
– designing a good graphical user interface is difficult, and expensive
– a good GUI is worthwhile, because the easier it is to try more things, the more things you will try, &
– creative insight is worth a lot more than programming skill

Even commercial software tends to be under-supported, and I’ll be the first to admit that my own programming is as buggy as anybody else’s, but if I’m making life-and-death or world-changing decisions, I want to be sure that I’m not the only one who’s looked at my code, tested border cases, considered the implications of missing values, controlled for underflow and overflow errors, done smart things with floating point fuzziness, and generally thought about any given problem in a few more directions than I have. I want to know that when serious bugs are discovered, the knowledge will be disseminated and somebody’s job is on the line to fix them.

For all these reasons, I temper my sincere enthusiasm about the wide open frontiers of open source products like R with a conservative appreciation for software that has a big company’s reputation and future riding on its accuracy, and preferably a big company that has been in the business long enough to develop the paranoia that drives a fierce QA program.

R is great for what it is, as long as you bear in mind what it isn’t. Your own R code or R code that you find sitting around is only as good as your commitment to testing and understanding of thorny computational gotchas.

I share the apparently-common opinion that R’s interface leaves a lot to be desired. Confidentiality agreements prevent me from confirming or denying the rumors about JMP 9 interfacing with R, but I will say that if they turn out to be true, both products would benefit from it. JMP, like any commercial product, improves when it faces stiff competition and attends to it, and R, like most open source products, could use a better front end.

And now let me make my case for R being an epic success.

I like open source software. I use a bunch of it, and I do what I can for the cause (which isn’t much more than evangelism, unfortunately). For me, the biggest win with open source software is that it makes tools available to me, and others, who don’t need them enough to justify much of a price, but who can benefit from them when they’re affordable or free. When an open source tool gets something done for me, or eases some pain at least, I’m not that picky about its interface, and I’m willing to do my own validation (where applicable).

I can’t say that I love using Linux, but as a long-time UNIX geek and Mac OS X bigot, I am glad Linux is available, I use it for certain things, and I think it’s a whole lot better than Windows and other OSes, especially when Ubuntu builds work out. (I’ve had trouble getting JMP for Linux installed on Ubuntu, but that’s probably due to my own incompetence.) OpenOffice is kind of a pain, but it’s better than paying Microsoft for the privilege of enduring the epic fail that is Office, and it has much better support than Office for import/export of other formats. I love it that any number of open source projects are developing such fabulous tools as bzr version control, which I use daily, and that the FINK project is porting a whole bunch of great open source UNIX widgets to Mac OS X.

I think it’s wonderful that some of the world’s greatest analytical minds are using R to create publicly available routines for power-analysts. I love it that students and people who can’t afford commercial stats software, or who won’t use it enough to justify buying a license, have a high-quality open source option, if they’re willing to work at it a bit. I think it’s great that people who think Excel is good enough can’t make a price objection to upgrading to R.

I believe that democratizing innovation and proliferating analytical competence are good for us all. I count on projects like R and Linux to push commercial developers to make better products, and to force pricing and licensing of those products to remain reasonable. Monopolies are good for nobody, including monopolists.

Long live the proponents of R!

What do you think? Do you trust open source stats code? Do you think R’s interface is good enough? Is JMP’s any better? How heavily do you factor quality of documentation into decisions about software?

This article was originally published in slightly-edited form by Multilingual magazine, October/November 2008 and is reprinted here with permission. Erin Vang would like to thank both Multilingual and her co-author, Tina Cargile, PMP, for graciously consenting to republication of these articles in the GlobalPragmatica blog.

Point: All five, all the time!—but mostly quality, time, and scope.

Erin Vang, PMP

Project managers talk about a “triple constraint:” scope, time, and cost. These are the three constraints where a change in one forces a change in the other. Increase the scope of a project (the amount of work), and you need either more time or more money to pay for overtime and extra people. Decrease the time available, and you’ll spend more on resources or need to cut down the scope somehow. And so on.

The triple constraint is usually drawn as a triangle with each constraint at a vertex and a haunting reminder of what’s really at stake in the middle: quality. The idea is that if you don’t keep all three in control, quality suffers.

Traditional project management triple constraint

A different triple constraint makes a little more sense to me—time, cost, quality—because it’s a no-brainer that more scope means more something else (cost or time or both), but what deserves our attention is how messing with cost or time affects quality. You can boil this triple constraint down to a pithy,”Good, fast, cheap; pick any two.” Or as a contractor friend of mine jokes, “If you want it bad—” (wait for it!) “you’ll get it bad.”

Even that triangle isn’t quite right, though. Let’s go back to the PMBOK where five constraints are listed: scope, cost, time, quality, and risk. Quality isn’t a result of your other choices, it’s one of the constraints, and you have choices about it. Risk is a constraint, too. Many project managers throw up their hands and ignore risk, but the thing about risk is that—here comes another cute line—”failing to plan is planning to fail.”

So we should be talking about a quintuple constraint, and the correct image is a pentagon. Let’s make quality and scope green (because more is usually better to our stakeholders) and the other three red (because less is better).

A better diagram is a quintuple constraint

The idea is the same: mess with any one of these, and at least one of the others also changes. But instead of drawing a warning “quality” in the middle as if it’s an uncontrollable result, and instead of ignoring risk altogether, we include both as the constraints (and choices) that they are. Our job is to execute projects with all five constraints in balance.

The shaded area inside the pentagon shows which of the constraints are most likely to keep me up at night in my work on the client side: quality, time, and scope. Some of our customers use JMP® software to make life and death decisions, so quality is paramount. We’re chasing tough deadlines, though, and keeping the scope under control is never easy. I am on a budget and manage a variety of risks, but cost and risk don’t usually keep me up at night because I can manage them over the long haul. It’s quality, time, and scope that have me putting out fires.

Tina on the vendor side wrestles with all five, too, but in different proportions that vary by client and project.

Counterpoint: Right now, it’s cost and time—but ask me again in 10 minutes!

Tina Wuelfing Cargile, PMP

When Erin and I first began collaborating, she introduced me to her five-constraint theory. At first it seemed odd and redundant, based on my traditional project management training on the triple-constraint theory, but the more I thought about the complexities of our industry and my client-facing role, I realized that I had intuitively been applying five constraints all along—I simply had not identified them as such.

As a multi-language vendor working in a wide array of verticals, I’m constantly looking at the question of determining fitness for use. It is one of the most difficult interrogative skills to learn or teach. Some claim that it is the client’s responsibility to communicate their goals accurately, which is technically correct, but I think serving in a partnership role with clients who may spend less than 10% of their time on translation projects is a more forward-thinking approach. Simply saying “Sure! You have a corporate bank account? We can fly you to the moon and back in two hours!” is not a winning long-term strategy.

Our primary industry sectors include legal, medical/pharmaceutical, and energy, but within those sectors, very different needs and roles emerge.

Legal translations involve the most diverse variations of constraints—from basic fact-finding, where time, scope and cost may be paramount, but quality and risk may be less important–to patent filings, where quality and time are often most important.

Medical/pharmaceutical work generally demands the highest levels of quality. Some translations just need basic research, but others have legal implications and need considerable vetting. Cost is not necessarily a primary factor, and an experienced project manager should advise the client on the risk of attempting a rush translation—often the rework needed to reach the necessary quality will erase any gains from rushing. PMs can assist by breaking the project scope into smaller, rolling deliverables.

Energy is a mixed bag—material safety data sheets (MSDS) must have top quality, and time and cost are usually not as critical.

Marketing materials for any of these verticals often have limited scope and time, but quality implications come first. Parsing trendy, creative writing aimed at US residents into text that makes sense abroad is one of the most difficult tasks we ask of our translators. (But seeing your company’s translation of an advertisement for disposable diapers is oddly thrilling!)

Whatever the business sector, risk management is what keeps me up at night. I work hard at proactively advising clients early and often about risks. Risk typically falls under the umbrella of cost but is inseparable from the other four constraints, in ways that can affect both client-side and vendor-side operations.

On the client side, say Big Pharmaceutical Corporation ABC who’s scheduling patients worldwide for a clinical trial or finalizing FDA submissions, a late delivery from us can disrupt hundreds of scheduled activities and milestones. My job is to understand the sequence of events that will unfold after our delivery, so I can advise the client upfront and help weigh the risks.

Risk is also critical for the vendor serving Big Pharmaceutical Corporation ABC. A delayed FDA submission might only lead to lower/slower revenue, but a translation error involving dosages or warnings could lead to patient illness or death. It is possible to limit our financial liability, but we could never limit our culpability or repair our reputation. So, I’m all for client education, but my focus is on providing leadership and consulting to avoid catastrophe. There is not a sleepless night nor weary day that I lose sight of the importance of the work we do and responsibility that we hold for our clients.