Introduction
Lauren Thorpe is not the type of person game historians typically write about. She has spent the bulk of her professional life running quality-assurance operations in the early (pre-iPhone) days of the mobile-gaming industry, which puts her twice removed from the designers, programmers, and business people who populate the medium’s historical imaginary. As a rule, quality assurance (QA), like most maintenance and repair practices, is seen as barely technical drudgery left to passionate—and massively underpaid—young testers.1 But as this interview will make clear, mobile QA prior to the so-called iPhone revolution was anything but unskilled. During this period, massive wireless carriers dictated terms, and key among those terms was that mobile publishers must portallof their games toeveryhandset supported within that carrier’s network. At the beginning of mainstream mobile-phone gaming when this meant producing half a dozen versions of a game, this wasn’t too difficult; but by the middle of the aughts, Nokia, Motorola, Ericsson, and the other handset manufacturers churned out new models with novel features at an unprecedented rate in an effort to differentiate themselves in a rapidly saturating market.2 It fell on Lauren Thorpe, her teams, and her associates at other publishers to do all the postproduction work that went into porting these games across these handsets at the same time that they troubleshot the myriad bugs endemic to early handsets. At a time when the industry’s number one priority was user acquisition, it is no exaggeration to claim that Thorpe and other QA professionals did quite as much as any designer or executive to popularize this new thing called “mobile gaming.”
Born and raised in Chicago, Thorpe earned a degree in sociology from Indiana University in 1991 before studying business and global management at Université Paris-Sorbonne and the Thunderbird School of Global management, respectively. Thorpe developed an early fascination with engineering and programming that would lead her, by fits and starts, to Netscape’s Paris branch early in the company’s lifetime. Her experiences at Netscape, as she explains in this interview, hooked her, and she moved “from tech-related field to tech-related field” that would lead her into the early mobile-content industry through the French mobile phone brand Alcatel. Her experience there led her shortly thereafter to a then-new company named Mforma, founded in 2001 as one of a brand-new breed of mobile game publishers who carved out their place in the market mediating between powerful mobile carriers and the small group of scattered developers then working on mobile development. At Mforma, she managed the porting and QA teams responsible for getting games onto handsets, which was, as she explains below, no mean feat. After departing Mforma in 2006, Thorpe moved to Los Angeles to take a job as director of services operations for mobile virtual network operator Helio, where she also managed the firm’s mobile content. Thorpe quickly tired of living in LA and left, after about a year, to help found THQ Wireless’s San Diego office, where she commanded much more influence than she had at Mforma. She ultimately left THQ Wireless in 2009 as THQ struggled to find profitability (THQ wireless would be sold off to mobile advertising firm 24MAS in 2011; THQ itself went bankrupt the next year). She then began a long stint at wireless powerhouse Qualcomm (also in San Diego), where she worked until 2017, at which point the mobile ecosystem had been completely transformed by the introduction and mainstreaming of smartphone technology and app stores.
As Thorpe explains throughout this interview, the early mobile industry was shaped—from production to distribution—by the needs and limitations of its QA and porting capacities. As the fragmentation problem worsened, publishers and porting houses had to develop novel strategies for getting the then-dominant licensed games onto handsets in time for their movie (or brand) tie-ins, which included changes to staffing strategies (such as Thorpe’s preference for college-educated computer scientists over cheaper student workers) and even changes to design (such as the so-called three-bucket approach to mobile development). Thorpe also goes into detail about the need for industry partnerships around maintenance and repair, as the most potent tool in her arsenal proved to be the alliances she struck with the National Software Testing Lab (NSTL), Qualcomm (where she would later work for eight years), and original equipment manufacturers (OEMs) like Nokia. Throughout, we can see how QA acts as a maintenance and repair buffer between development and consumption, intercepting and correcting the numerous errors lurking within the decade’s deluge of devices.
This interview was conducted on November 23, 2022, via Zoom, with Thorpe calling from her home in San Francisco and I from mine in Bloomington, Indiana. This was the second interview that we recorded and was recorded over the space of sixty uninterrupted minutes. The original interview transcript has been lightly edited for clarity.
Glossary
Since this interview is as much about the obscure origins of cell-phone-based mobile gaming as it is about QA, I will conclude with a brief glossary of important terms that appear in it, as well as some further contextualization of this period’s unique market structure.
carrier/operator—Carriers, sometimes called operators, were telecommunication providers like Sprint or Verizon who owned and sold access to actual wireless infrastructure. Another class of operators—called MVNOs or mobile virtual network operators—did not own any physical infrastructure but instead sold access to competitors’ networks. The carriers dominated the early mobile industry so completely that they were able to dictate terms to the rest of the industry.
mobile publisher—Early mobile publishers were companies like Mforma, JAMDAT Mobile, and THQ Wireless who acted as intermediaries between carriers and developers. Unlike console publishers, whose efforts tend to center around marketing and distribution, mobile publishers derived their value from control over the difficult processes of porting and QA.
deck—Each carrier offered their company’s games through what was called the deck, which was a very simple, text-based store menu. Games were listed alphabetically at first, and later by popularity.
BREW—Binary Runtime Environment for Wireless, or BREW, was a distribution platform for mobile phones developed by Qualcomm. BREW offered developers numerous development libraries and easy end-to-end support, as compared with its primary competitors, Java 2 Micro Edition or J2ME. BREW was not as widely supported as Java, but it was the platform of choice for Verizon, which gave it an early market edge.
BREW certification—Part of Qualcomm’s pitch for BREW is that it would be more reliable and more comprehensive than Java. As part of this guarantee, Qualcomm required that all BREW applications pass a battery of tests to ensure that they ran reliably prior to being sent to carriers, who would typically run the tests again before final approval of the game. These tests helped prevent buggy (or, worse yet, malicious) software from getting onto carrier decks, but at a price: developers had to pay a four-figure fee every time they applied to Qualcomm for certification. If a game failed once, the developer would have to pay again to retest.
test plan—A test plan lists the steps and tests that a game has to undergo prior to certification and/or release. In the BREW ecosystem, this plan was invaluable as it allowed testers to be sure a game would pass Qualcomm’s test, thereby saving the company additional testing fees and shortening time-to-market.
Interview
Logan Brown [LB]: Can you tell me a little bit about your upbringing and what brought you into the tech industry in the first place?
Lauren Thorpe [LT]: Sure. I grew up for the most part in a North Shore suburb of Chicago. I was always very curious as to how things worked mechanically. My parents were rather supportive, so if the toaster died they handed me the toaster and a screwdriver to take it apart to figure out what happened. In our community there was a local YMCA that had after-school programs that were all about building things—I think today it would be the equivalent of the Maker Society—so I would through this program build metal detectors and radios and things that required a little bit of soldering and circuit-board etching. There were a bunch of things like that that we made that helped me to understand how things worked.
I did get an early computer. I did a little bit of really basic programming—you know, get a diagonal line to draw and a spiral on the screen—so I was curious about how … I don’t even remember what the computer was anymore. But I was curious as to how that worked. It made it so that I wasn’t afraid of technology and I wasn’t afraid of machines, and they inspired curiosity. I took some computer-programming classes in college out of curiosity and interest, not out of a desire to go into that space. I took BASIC, I took FORTRAN, and then when I got to Pascal I’m like “This isn’t fun,” so I stopped.
In terms of how I got into the industry, it was honestly just luck—right time and right place. My first job in tech was a press-relations coordinator, a PR coordinator, for Netscape Communications in their European headquarters in Paris. And they were literally just looking for someone who spoke English fluently, and I happened to be in Paris looking for a job. And I went to some function and I met them there—I didn’t even know what Netscape was at the time. I had no idea what an internet browser or anything was. But once I started I absolutely fell in love with tech and hopped from tech-related field to tech-related field after that.
LB: So how did you get from Netscape to the mobile industry?
LT: A relatively logical path, even if it didn’t seem like it at the time, I guess, with hindsight. When we were at Netscape we talked a lot about the cloud—not necessarily today’s cloud, but communication and where that communication went. So I went to Alcatel, learned a lot about IP [internet protocol] networks, learned a lot about WAP—which was that wireless access protocol, that early communication protocol for data on mobile phones. Learning about IP networks was super boring, I did not stay there long! But that got me to work for a startup that was trying to monetize the internet in the early days by inserting tokens in the IP packet, and so it needed a gateway in the end. That did not go over well, because when you have to sell to two different customers, your company dies very quickly. But from that I moved to a company, another startup, that was working on a better GUI [graphical user interface] for developing mobile applications. And from thatone (because again, it didn’t survive) I ended up at Mforma, because somebody I’d worked with at Alcatel was at Mforma, and I had suggested that they acquire the developers from the startup I was working for that was dying, and they said, “Well, we don’t need developers based in Colorado, but if you need a job we’ve got one for you.” And that was what got me over.
LB: When you finally ended up at Mforma, which would later become Hands-On Mobile, I believe you were leading the postproduction teams, right? Can you tell me what postproduction looked like at Mforma at the time and how maybe this postproduction process might have differed from what was happening in the console and PC spaces?
LT: Sure. At the time I started, it was just the beginning of BREW, so there were about a handful, maybe three or four devices, that were running on the CDMA [code division multiple access, a Qualcomm-developed network standard] network using BREW to run applications. There were probably five hundred Java devices out there at the time, so there was already pretty deep fragmentation when it came to Java, and the beginning of some pretty intense fragmentation when it came to BREW. We had I think two QA people at the time, and it was just really early days in what app development would look like. Over the next year, the number of Verizon devices—I suppose I should say BREW devices, because they went beyond Verizon, though that was the primary carrier—grew to about sixty-five. The number of Java devices grew to about nine hundred. The number of handset manufacturers grew. The number of carrier requirements for testing grew, and because the space started to make a little bit of money and get some excitement, the pressure on release timing, hitting a date … You know, if a movie was coming out with a game to be paired with it, all of a sudden you hadto hit that date. So there was a lot more marketing around mobile applications and mobile content that was tied to other events, and so there was more pressure there. I’d say the biggest thing was the beginning of that fragmentation. Each one of those handset manufacturers had its own firmware on those devices, and even that firmware would evolve from device to device, so there wasn’t a lot of stability in the environment that we were working in.
LB: So the mobile industry moved even faster than the rest of tech in the [first decade of the] 2000s—things spun out really, really fast and led to a lot of the fragmentation you’ve mentioned, led to a lot of people bouncing around between companies and so forth. So can you just summarize how you moved through the mobile industry through the [first decade of the] 2000s and early 2010s, and what your positions were at each place?
LT: You’re right, mobile games were a very expensive thing to produce and do, and most of these companies were startups that were getting involved in this space. And so there was a lot … I suppose I should say there were divisions of big companies, but those weren’t always well funded. So there was a lot of growth and shrink, lots of highs and lots of lows. And so a lot of movement in that industry was driven by people’s jobs disappearing, and so they hopped onto the next startup that was trying to do the same thing. I don’t know how much of it was seeking better opportunities so much as forced labor movements.
For me, I moved from Mforma to an MVNO, a mobile virtual network operator—so a new carrier that was running on Sprint’s network. I moved because I had done a lot of things at Mforma and I wanted to continue to learn new things, so I thought moving to the operator side of the business would be interesting. Helio [the MVNO] was a joint venture between SK Telecom and Earthlink at the time, and I ran the service operations. So I was responsible for getting content into the operator store. I got to manage the game store, basically. I had a team that worked with the developers to get them to port their titles to the Helio devices. I worked with the actual developers so that we could ingest the content coming in for the app store. Helio had some of its own applications, a modified version of Myspace at the time, that was a little early on. Also device requirements, I worked closely with the device team on what’re some of the requirements that’re gonna help developers to be able to make great experiences, great games and apps for these devices. And getting these devices plugged into that back-end system. So I basically ran the end-to-end of the back-end system from a carrier perspective, an operator perspective.
I did that for about a year. I had a lot of challenges related to living in LA, I don’t know why anybody would choose to live with that kind of traffic; that and the pollution. So I sought out a new job and found a job with THQ Wireless. THQ was an established game company at the time, and they had really been trying to get their mobile-games business up and running, and they were running into a lot of challenges associated with mobile. Having been there and done that before, they hired me on as the VP of Operations to deal with both production and postproduction operations. So that chain and how you can make it even more efficient from the very beginning, when the production of your game to make postproduction be more efficient and less painful. At Mforma I only owned the back half, so I had to take what was given to me. And there was a tremendous amount of learning that could have been done better if there was a holistic view on that entire process. Things like: rather than build a high-end game that you then have to try and cut down to make it work, have three different targets, a high-, mid-, and low-end device-capability game that you could then put through [postproduction], and then that made the porting much less [difficult]. The amount of variation, the amount of introducing risk and bugs because you’re changing everything every time—it cut that down multifold. So those types of things.
LB: That’s a nice segue into what I think is the element of your purview at that time that I’m most interested in today, which is the QA question. Last time we spoke, you had impressed upon me that QA was kind of a nightmare in mobile, and certainly everybody else I’ve spoken with has said as much. And I’m curious: what made QA so complex in the mobile space, and why was it so important in that space?
LT: So I think the complexity had to do with the hardware you were targeting. You had a hardware platform with limited capability, and then it had different firmware. For example, what audio file types a device supported would be different between Motorola, Sony-Ericsson, Nokia … And so you had to understand what the device was capable of. Eventually we built a tool to profile the device, and we built this because the QA engineers said, “This is crazy! We have to know before we start what we’re getting, you can’t just give us something.” And these are great learnings that we went through and built internal tools from them. So I think the complexity came from the fact that every device was different. Literally. Every. Device. Was different. Even if Nokia said, “Oh, this falls in this family,” in Nokia’s mind that meant maybe that key mappings were all the same, but maybe it supported different audio file formats, maybe it had a different chipset in it, so a different performance threshold. And sometimes it just had a bug! Sometimes there was just a firmware bug, so it would play audio and then you’d hit a key and then it would stop and it would never come back. Or a phone call would interrupt the gameplay and then audio would never come back or the game couldn’t resume. It wasn’t necessarily a bug in our code, it was a bug in the firmware. At the time, the [development] cycle was too short to try to go convince those guys to go fix the bug in the firmware. Instead, it was all about how do we fix our code to gracefully deal with whatever bug we found. So QA was complex because the devices were so different. And that was out of our control. So it was really important to not just have college kids who liked to play video games as QA testers, because you really needed somebody to understand and be able to dig in to figure out what the issue was. That was important.
Another area of complexity that was expensive was just the testing requirements, test plans that you needed to pass. Some of them were obvious, meaning that some of them were provided to us, and some of them weren’t, so we didn’t know what tests the carrier was going to run. So you would fail and you wouldn’t know why you failed. And failing meant a bunch of fix-tested resubmissions, which could delay a launch, and if you’re trying to launch in time for a movie release, that was super expensive. So there was a lot of work that we did to try to work with the carriers in creating an understanding of their test plan, a pre-cert program, whatever we could do to avoid that scenario of failing. A lot of negotiating how important an actual failure is, basically anything to get the device out the door.
LB: This is a good time to ask: Is the likeliness of that failure and the expense of that failure why certification was such a big deal? That [certification] let you fast-track past some of those issues?
LT: Yeah. The ability to have a trained QA team that understood what the test plans were and accumulate carrier failures into our own database and create our own understanding of what those test plans were through volume and experience, those types of things are what really helped—from an Mforma perspective—to get a really high bar to pass certification. We did what we could! We made friends with the guys at NSTL [the National Software Testing Lab], we had them come and train our testers on the test plan in the same way they train their own testers. Literally anything you could do to improve your QA team’s understanding of how to get through certification was going to save you time and money, which arguably were the same thing.
LB: That brings up my next question, which is: how exactly were you recruiting the employees who were doing this QA work and some of the porting work? Were you looking for workers with any particular skill sets? Were you talking about relatively fresh college graduates? Senior coding types?
LT: We were looking for computer-science engineers who were fresh out of college. This was while I was at Mforma, so there was a tremendous number of folks who’d graduated from local universities—we’ve got three or four down here to choose from. San Diego has an interesting peculiarity in that there’s not a lot of employers, but Sony was actually down here. So if we got anybody with experience they might have had a year of QA at Sony—otherwise they were fresh out of school. But getting an engineer was helpful for two reasons: because they understood why they were doing what they were doing and what they were looking for, and they could help and improve upon tools. Mforma was a startup that was growing rapidly, and those guys moved pretty rapidly out of QA and into the porting teams, or the software application development teams. Or even the back-end server teams. So by bringing in more skilled labor in that entry-level job, we made an internal flow where we could promote people to where they were using the degrees they had. When I got to THQ Wireless, the QA team was mostly … I would say highly unreliable college kids who would come in for a few hours and they would either get put on testing console games or they’d get put on testing mobile. THQ Wireless’s quality in mobile was horrible. And so one of the big changes I made was shifting to a more stable workforce. And also shifting the profile. We ended up paying those people more than what the profile had called for previously, but as I mentioned that time-to-market, getting things through the first time actually saved a ton of money in the end. So even though we had to pay our employees more, they were worth every penny of it in the overall scheme of things. So whether it was by accident or on purpose, what we did at Mforma really paid off and proved itself out when I got to THQ Wireless.
LB: So you alluded to this a few minutes ago, but it’s worth clarifying. Beyond whatever they learned in college, what kinds of training regimens were you then giving these young programmers when they arrived? How was that training conducted?
LT: Well, NSTL, the National Software Testing Lab, had a hundred—I don’t remember the exact number, but we’ll say a hundred different test cases broken up into different categories. When I got there [Mforma] there was one trained employee, one employee who’d been doing this for a while, and so he continued to train the guys who came after on the test plan. But we were fortunate, the NSTL folks were local to San Diego, so we invited the person who was leading the testing team to come over and do a training for the Mforma (and later THQ) QA teams so they could hear how—not just read the test case—but actually howthose testers went about doing the actual tests. Because the test case might say “you need to pass x” and the tester does it by doing y seven times in a row, or key mashing, whatever they did. So understanding howthe test case was actually being run by the people who were going to pass or fail you was tremendously valuable to that team.
LB: We’ve already talked a little bit about the fragmentation problem; porting has come up a couple of times because there were so many handsets and so many carriers required that you target all the handsets that they supported. So how did the porting work at Mforma and later at THQ Wireless? And how did that relate to QA, if at all?
LT: At Mforma we—and when I say we it was a combination of QA engineers and of the porting engineers—actually built an internal tool to facilitate porting. Any smart developer, if you make them do the same thing twenty times, they’re gonna look for how can I reduce my work, and what are the things that are consistent that I can automate or improve upon. I would say at Mforma we had probably three strategies (we tried probably twenty strategies). External developers, external porting houses, which fell into two categories: offshore, where they just threw a bunch of people at it and it was all done manually; and some of the external porting companies had actually built their own porting tools. We tried to license a third-party porting tool and then built some aspects of a porting tool ourselves internally. And then we did have engineers who would just grind through something if something needed to be done; if some handset went rogue and we had to support it, they might manually port just that, target that one handset just to get it done. So I would say we used every strategy under the sun, and over time learned about who was reliable and who was good at what, and which tools were more efficient or ineffective depending on the type of game.
It [porting] had a direct impact on QA, because if you’re using a third-party porting house, you’re expecting to get a gold master back for what they do. We still had to QA everything that they delivered, so there was a lot of discussion about what is that right level of QA. If you hired a porting house that did all of their work in India, it didn’t have access to any of the physical phones (or very few of them), the amount of work you had to do when it came back in was much higher. But at the same time, if you got to pay a lot less money for that, and you could put it on a title that didn’t have that much time pressure, one that wasn’t tied to a movie release, then you could do that as an offshore strategy knowing you’d have to QA it, knowing there would be a bunch of back and forth and you wouldn’t expect the same level of quality. Not because the team in India or wherever it happened to be wasn’t qualified, but because they didn’t have access to the devices so they weren’t testing on-device. So there was a direct correlation between what porting strategy you used and how that would impact QA.
LB: I had had the impression that Mforma had kind of experimented with offshoring and that that didn’t necessarily work out for the reasons that you listed, but it sounds like these were all on the table depending on the needs of the project. Is that correct?
LT: Yeah, definitely some were ruled out. If you were a porting house and you didn’t deliver on time once, there was no point in giving the porting house a second chance, right? It was just too expensive to mess up. Over time I think we narrowed it down, and you spoke with Mark Vange, who ran Ketsujin, and they were fantastic so that was our high-quality external porting. We had an internal porting team who used the internal tools that we built, so certain titles would flow right through. If you think about it, if we built the title internally, we would use our internal porting team to port it, because if there were bugs or other issues then we had direct access. So some of the high-value titles that had really serious deadlines, we did the whole thing internally because everybody was sitting next to each other (or close enough). If we paid for a third-party developer to build the original title, then we might put it out to Ketsujin to do the porting, and then put those two companies in direct contact with the project manager on our side sitting in. Then they [Ketsujin] could go get the fixes they needed from the original developer. If there was a bug that they found in the original code. It was interesting, because all QA teams, before they start postproduction and start porting, they would QA even though it had been QA’d already and sent to them as a golden master. The postproduction teams knew the cost of replicating a bug across multiple devices, so they would re-QA it on a couple other devices just to make sure what they were getting was quality. And Ketsujin would do the same. We did a lot more alignment of third party to third party, external versus internal to keep the flow going, and then we would divide up our development roadmap based on our internal team’s skillsets as well as whether it was a licensed title, as well as what the timing was. There was quite a bit of intention behind where things went, I don’t mean to make it sound haphazard, but every once in a while we’d try something new, because maybe there’s something better out there. So I’d say there were always options that we considered.
LB: It doesn’t sound haphazard at all, if anything it sounds—given the importance of hitting day and date—that this had to be a very precise machine! It sounds like a lot of your job was keeping all the pieces functioning according to those deadlines—the time element was your major purview, right?
LT: Yeah. And if you think about it, there would be new devices coming out the door at the same time, so how do you get your hands on brand-new devices, so negotiating with the Verizons, the AT&Ts, and the Sprints of the world to get early access to a device. If you’re doing a title for, you know, Lucas for Clone Wars that’s supposed to line up with the new animated TV show Clone Wars and Verizon is gonna do a marketing campaign to promote this, and at the same time they’re supporting a brand-new Motorola phone and that’s what they’re going to market this on, you’re begging to get your hands on that Motorola device. And if it’s not something that you happened to build internally, like maybe you used a third party, then you need to get that Motorola device and not only get it but get it and give it to whatever the developer is that’s working on the game and the QA team! There were a lot of parties involved even if it felt like it was a purely internal thing, because you had the licensors who had to approve content, you had to get your hands on devices, you had the carriers’ games team, where they’re going to put it in their store, marketing assets and approvals. It was a bit of a … yeah. There was a lot going on.
LB: That sounds like a nightmare! So, it’s hard to argue that the iPhone and the app store, when they released in 2007 and 2008, respectively, really reconfigured the entire mobile games industry, right? The entire production pattern shifted. I think that at the time that the iPhone came out, you were still at THQ Wireless—how was the iPhone received by THQ and by your colleagues at other mobile game companies?
LT: Well, I certainly can speak to THQ, maybe not to others. There was actually a huge internal debate: Is this a phone? Or is it a game console? Its performance was similar to a Gameboy. So there was a lot of confusion and debate that would happen. Does it go to the wireless team? Or does it stay at headquarters with the console team? And the license agreements that we had—we had to go back through the license agreements to try to figure out where does this device fall in, to which category? At that point in time I think there were five SpongeBob titles being pitched to Apple at the same time because THQ Mobile had a SpongeBob license, THQ console had a SpongeBob license, I think Nickelodeon owned it and their own internal games team felt that their own internal games team could work with their own IP ... It was in a bunch of different categories. There was great excitement about it, but at the time it was really messy on several fronts.
LB: Was there any idea that the iPhone might be worth targeting on its own, or was that just another device to add to the list of devices to hit, given that targeting just the iPhone and eventually iPhone and Android could obviate the need for all the porting and much of the QA headache?
LT: I think it was treated as a separate device on its own primarily because its input was touch and that was one of the first dramatic changes in inputs; it wasn’t about key presses. And it had better performance. So those two things put together, game producers sat down and asked, “What can I do with this?” And it had better audio, so all of a sudden you had … You know, audio provides so much in a game but when you have a flip phone your audio was … It wasn’t limited to beeps and blips, they could play MP3 files and WAV files at some point in time, but you know the quality of audio and the impact was more about sound effects and not about music in a game. And now all of a sudden you had something that had performance, it was a minicomputer. So it had performance capabilities; it had audio capabilities; it had a different input method that was touch, so it had all sorts of different experiences. It had higher-resolution graphics. So I think it was slightly more perceived like a console than a phone in the sense of what are the things I can do and what are the assets I need and how do I go about this?
LB: So after THQ you actually ended up going to work at Qualcomm for quite a few years right around this time, 2008, 2009. What were you doing at Qualcomm and how did Qualcomm respond to the release of the iPhone given the importance of BREW to Qualcomm’s place in the industry at that time?
LT: I was hired at Qualcomm as the senior director of ecosystems. Really what I was hired to do was to help Qualcomm manage the … we’ll call it the long tail of BREW. So there was already a recognition that the industry had shifted, that things had changed dramatically, but Qualcomm had contracts with a bunch of carriers and needed to continue to provide service to those companies. So I was brought in to do two things. One was to continue to work with developers. So having come from the developer side, what does the developer need or want to continue to work with Qualcomm even though there’s this Apple app store hanging out there. And the second thing was basically how do we make this profitable. Because at THQ, the reason that THQ Wireless actually was shut down was because it was really hard to be profitable with mobile games. It was sort of hanging on that profit line somewhere around breakeven. And THQ wasn’t the only one: Mforma had the same cost constraints; everybody had those same cost constraints. And so the question was: what could we do at Qualcomm around BREW that would improve profitability for the game developers and the app developers so that they would want to continue to supply and support BREW for its long tail, however long that end-of-life was going to take?
LB: And how did you manage that long tail?
LT: A lot of things! I renegotiated the contract with NSTL to reduce the costs because the developer paid per handset to get games tested by NSTL. Finally got my hands on that Verizon QA test plan and showed them where there was overlap with NSTL, so significantly reduced the amount of testing that had to be done on the games in general [and] improved the time to market. Worked with Verizon and the others to reduce the number of required handsets. Showed them how handset families worked so that they could understand that even by reducing the number of required handsets they still could have great coverage—so basically reduced the cost for a developer to support, you know, getting a BREW application out the door. What else did we do … Never did quite get around to fixing the business model in terms of the developer revenue share. That one—I don’t think—happened, or if it did it was much, much later. But definitely huge improvements on the cost side of the business. Worked really closely with Verizon when they were commissioning new phones, worked with those OEMs and gave them a sample test application for them to run so that they could catch firmware bugs up front, so that there was better device quality when those devices finally came to the market. So developers had fewer exceptions that they had to manage. So those were probably the primary things.
LB: Was that the first time you actually managed to get OEMs to address some of the more pernicious handset bugs prior to device release?
LT: Yeah. Verizon had its own QA, and they would QA the device, but that QA process didn’t include really running software applications on the phone. It was more about calls and dropping calls and connectivity. So we addedto Verizon’s test plan, basically, for devices.
LB: So to conclude with a couple big-picture questions: this doesn’t seem like a long time in retrospect, but in this early period the five years or so that you were involved in the industry prior to Qualcomm was a pretty good chunk of this early, formative period. So I’m curious how you felt that this industry changed, evolved, matured or didn’t mature during your tenure in the early industry.
LT: Oh I think it matured tremendously! Tools were built, understanding of devices … tools for understanding device capabilities were created. Great developer strategies on how do I efficiently create a great user experience for each device capability—so, “How do I build knowingthere’s fragmentation, and then what are the tools I can use to do that?” Even an understanding—it was kind of a novel concept—that the game might be called the same name, but on a low-performing phone maybe it’s a self-moving side scroller—so the only keys you’re hitting are to jump or roll or duck, whatever—versus moving, trying to move the scroller. And then on a higher-performing device then you could handle both moving the side scroller as well as other activities. Calling the game the same thing even though they were significantly different in the experience. Getting over that fear of what it is I’m delivering. So I think there was a lot of great maturity and strategies around how to deal with fragmentation that came out over that period of time.
LB: Well, that’s a fantastic conclusion. Ms. Thorpe, thank you so much for speaking with me today. I appreciate your taking the time.
LT: It’s an absolute pleasure.
Footnotes
1. ^ The notoriously poor pay and working conditions that many testers face has led to a recent push in labor activism among QA professionals. See Nicole Carpenter, “How QA Workers Are Driving the Video Game Industry’s Union Push,” Polygon, July 20, 2022, https://www.polygon.com/23270642/union-video-game-industry-qa-activision-blizzard-keywords.
2. ^ In 1992 there were only seven new handset models to hit the market from three major firms. By the year 2000, the number of new handsets per year had ballooned to 241. By 2003, the number had almost doubled to 402. Heli Koski and Tobias Kretschmer, “Innovation and Dominant Design in Mobile Telephony,” Industry and Innovation 14, no. 3 (2007): 305–24.