Why Testers Need to Code: An Interview with Simon Stewart


In this TechWell interivew, Facebook's Simon Stewart discusses the social media company's unique mobile approach, the application's fast and hard development cycle, and the key to the speed of all those updates that arrive on your phone. 

Josiah Renaudin: First off, please tell us a bit about yourself and your role at Facebook.

Simon Stewart: I’m a software engineer in Facebook’s London office. My original team worked on developing the APIs and infrastructure we needed for automated testing of our mobile apps on Android and iOS. We ended up using and contributing to the open-source projects “Selendroid” and “iOS-driver,” and we now run a stable subset of our end-to-end tests for every change we make to our Android and iOS apps. It’s a great team to work with and, thanks to their work, we’re in a position to use the same set of abstractions we use for our “correctness” tests for other purposes, such as performance testing.

I’m now focusing on our build tool --- “Buck” --- which, again, is open source. Buck started life as being an amazingly fast way to build Android applications, and we’ve been working hard to extend it to support not just Java and Android but also native code development for our back-end services and iOS.

I’m sure you’ve seen the XKCD cartoon with two developers fencing on chairs explaining that they’re not being lazy, they’re waiting for the code to compile. The Buck team’s goal is to make sure that Facebook’s developers never get a chance to use that excuse!

Larry Wall once wrote that there are three attributes shared by all great programmers: laziness, impatience, and hubris. Taking each of those, in this case “hubris” refers to wanting to write programs that no one wants to say anything bad about. “Impatience” is about the desire to have the computer react to your needs as close to instantly as possible. “Laziness” refers to wanting to reduce energy to complete a task: You’re willing to work really hard to solve the problem in an automated way so that you never need to expend effort to solve it again. I guess you could say that the theme of the work is to allow developers to be lazy, impatient and hubristic.

I am also the lead of the Selenium project, and created WebDriver, which came out of the tribulations building and verifying software that the teams I worked with went through. There’s nothing like first-hand experience to reinforce the lessons about what’s important and what’s not. Right now, the W3C are working on “WebDriver” specification, supported by Google, Microsoft, and Opera amongst others. Although we’re working hard to get to Last Call it’s a ways off, but there are already implementations for Chrome, Firefox, and Internet Explorer. It’s been absolutely wonderful seeing the browser vendors add support for easier automation to their browsers; I feel it’ll make the lives of many developers and testers a lot easier.

Josiah Renaudin: Can you explain just how big a piece of the Facebook pie the mobile department is? What percentage of Facebook users access your app, compared to its web companion?

Simon Stewart: My impression is that Facebook does things very differently from other companies, and I think that makes it an interesting company to work for. We don’t have a “mobile department” since we found that hard to scale appropriately. Instead, teams working on features, such as photos or the News Feed, own that feature on every platform we support, from the mobile web, “traditional” desktop browsers, through to mobile platforms such as iOS and Android.

This approach means that when a team releases a new feature it happens at about the same time on every platform. As an Android user, I used to find the lag in features after an iOS a source of bemusement, so I think that the current approach works out better for most people.

Having said that there’s no mobile team, there are, of course, individuals who are particularly familiar with the individual platforms, and there are small teams dedicated to providing common infrastructure on mobile that all the feature teams can use, just as there are teams working on providing infrastructure for use by our web developers.

I’m not sure of the exact numbers of people using the app as compared to the web, but I do know that mobile traffic is increasing and in some countries surpasses desktop usage. As the shift from desktop to mobile has been happening, we’ve been working to make the apps perform better under the constraints of mobile. The first big move was our shift from using web views (which allowed us to iterate really quickly) to writing native apps (which, certainly at the time we made that choice, gives people a smoother way of using Facebook). The improvements we’re making now may be less obvious, but we have automated tests which track things like power consumption, memory and CPU usage, and how we use bandwidth, the goal being to improve (or, at least, hold steady) all of those metrics with each release.

Josiah Renaudin: How do you determine what you want to focus on with each Facebook update? What’s that process like?

About the author

Upcoming Events

Jun 04
Jun 04
Jun 12
Apr 29