At first glance, Jeremy Wright may not seem important: he’s just a product engineer for the world’s largest and most popular GIS. But when I was meeting and interviewing people in San Diego at the Esri UC for xyHt, I made a point of searching for Jeremy. He’s passionate about his work and heavily involved in Esri’s newest and most impressive software, ArcGIS Pro.
When we think of Esri, we might think of a money-making machine or a company that is out to make a quick buck, but Jeremy is really what Esri is all about. He cares about the product – so much that he takes time out of his “day job” building the Graphics engine inside ArcGIS Pro to monitor what people say about Esri software on Twitter to see where things could be improved.
Nicholas Duggan: Hi Jeremy, what is it that you do?
Jeremy Wright: I’m a product engineer. In Esri software development, we have two divisions, software development and software products. Software development is the one that builds the production code and they build the code that actually does the work.
And then the software products team does everything else [related to building the software]…requirements analysis, design, user experience, and then [validating] acceptance criteria … verifying that everything meets those acceptance criteria when we ship the software.
That could mean writing up designs, writing automated tests… It could be running through workflows manually in a lab with computers somewhere, lots of different stuff.
Essentially, the products division is dedicated to being the voice of the user. They make sure that when the software development team builds functionality, it’s understandable and easy to use.
ND: Is there a huge chart or a huge workflow—a big sheet that you guys work to?
JW: We do have larger themes of workflows that our users need to be able to achieve, and typically those are embodied through epics in our development roadmap. We use the agile process using scrum methodology.
ND: Scrum?
JW: Scrum methodology is when you break up what you need to do into units of work that are able to be done in a single sprint or iteration. And then all the teams work towards those goals collectively.
Making sure that the teams are working on the right chunks of work is the job of the epics; they can be overarching. They can be across multiple teams, and even multiple products. So we try to coordinate any cross-team tasks with these epics, these bigger stories – [they’re] things that people need to be able to do.
So for instance, editing scene layers: [“Scene Layers” is Esri’s term for geospatial data streamed in 3d scenes using the OGC standard I3S format http://www.opengeospatial.org/standards/i3s ]
That involves not only the scene layers team and the graphics team, but also the online, server, and enterprise folks. So, it’s a larger effort that requires work from several different places.
The methodology that we use is less important than knowing what the user wants to do—we need to know the things that users want to be able to do with our software that they can’t do now and the things that we need to be able to build for them in the next few releases—and that’s where we get our roadmap.
The Pro roadmap is also publicly available. You can go online [https://go.esri.com/ProRoadmap] and you can see it. It’s always updated every time we do a release. And that, in broad strokes, is like our list of work that we’re going to do.
ND: Do you stick to that, or do you have a slightly longer roadmap that nobody knows about and nobody will know about?
JW: There’s two answers to that question. One is: in the actual publicly released roadmap, there’s this long-term bucket, and that’s sort of ephemeral. It’s really the things that we know we need to do, but we definitely won’t have time to do it in the next two to four releases. And so, we’ll evaluate at each release, the priority of the work that we do based on user feedback, based on trends in the industry and that kind of stuff. And we’ll definitely course-correct at every release.
The second answer to that is: yes of course. Some of our core technology teams—like I work on the team that builds the graphics engine inside of ArcGIS Pro—there is functionality that we know we need to have in the next five years. And so, we need to start working now to build the foundation for that technology in our graphics engine, even at this release. And because of that, we have changes that we have to make behind the scenes that no user ever sees until two or three releases later.
ND: How do you know how the features need to look when you can see that the whole of ArcGIS Pro? How would you know how that feature is going to look? Say, for example, the Web Scene: so you know you’ve got to have web scenes and they’re going to be 3D. How do you know what they’re going to have to look like in like five years’ time when you actually put it in?
JW: Some of it can be gleaned from user requests first off, and some of it can be gleaned from the type of work that users are doing. “This would be really useful for the user.” An example is like the range slider, right? Nobody really asks, “Hey, I want this slider that can change between ordinal values in my data,” but as soon as we have the concept in something that we knew we needed to build, we work towards it. Yes, that’s totally useful. I can use it for floors. I can use it for subsections, or whatever I need to use it for. It’s just this tool that I can use for many different things.
At Esri, we spend more on R&D than almost any software company. It’s almost 30 percent of our revenue.
ND: Jack Dangermond was talking about that this morning.
JW: It’s something to be talking about, definitely. I mean, we build tons of stuff that never sees the light of day, but it’s all building toward things that our users will be able to use and technology that our users will be able to use.
So 28.9%—that means that a third of the time, our people in both software products and software development are working on concepts that we’ve come up and said, “Hey, I want to start this project that does this. I think it would be a really good idea if we had this.” And we work towards it and we prototype it.
And then, when we need to actually productize it or turn it into a thing that our users could use, we definitely need to make it fit in the constraints of our normal software products. But we have many people who are working on long-term stuff that isn’t going to see the light of day for three, four releases.
ND: So you say you’re a products guy, and you’re quite modest about who you are and what you do, but you’re quite proactive and always watching what is being said about the software.
JW: It’s been an unofficial responsibility. If you are in product engineering, you’re designing products for the user. You need to be aware of what your users are doing and the challenges that they’re having with the existing software and make changes.
Now, there are people that would say, if you ask users what they want, you’re going to build the crappiest software on the planet because it’s going to be a mish-mash of things that random people want. So we do still have to put some structure to it. We still have to consider things in context, like which customer is asking for it, what type of work they do, what industry they represent.
But the situational awareness part the job—of being in products in general at Esri especially—is you need to be aware of the larger picture. So we have junior product engineers, and they focus on a specific sort of area of even just one part of the software, and then the senior product engineers on our staff and some of the people that you’re familiar with and you spoke with like Craig Williams, those are people that are aware of the larger context of our work. Not just the larger context of our work in terms of ArcGIS Pro, but the larger context of our products and how users use them. So it’s just something you kind of grow into as you are in product engineering. I started in tech support.
ND: That’s where you came from?
JW: Yeah. My first job out of college, I worked in tech support at Esri, and then three years came by and I had been working with the development staff. The team I was working on in tech support was responsible for essentially “Windows internals”, installing and licensing the software and then interfacing with printers and digitizers. You know, digitizers, old school.
But I worked with development, and they were just like, “If you want, we have a position open. Do you want to come up?” And I had to interview, but that was how it happened. After I started in development, I just started working on more and more stuff. It’s just one of those kinds of companies where, if you show an acumen and you have an ability, [then you] just go do that thing and take on that responsibility.
ND: So has that drive ever got you into trouble?
JW: I’ve gotten into trouble before. I think the biggest challenge is that when you’re younger and you have a passion for whatever niche part of the software you’re responsible for, you tend to get tunnel vision—it’s another perspective thing. It’s like you only have the furor or the passion for getting things done in your area, and you don’t see the larger picture. And it’s what I encourage all of my employees to do, is to actually take that context and try something that you don’t know about, and then that will actually give you context for the work that you do.
It’s important to know what other people do, too. I mean, it’s like being a citizen in this global world, right? You have to think about, not only what you’re doing and how that pertains to your state or your country, but how it affects other people. And it’s the same thing with product engineering: Play nice with others.
Give anybody a certificate and they’ll think they know everything about something, right? So that’s what’s gotten me in trouble—just not having the perspective. Now that I’m working with the company for a little longer—I think I’ve been there 17 years.
ND: Oh wow. Has it been 17 years?
JW: I know we’ve been chatting for like five years, So yeah, the longer you’re there, the better you understand the larger context of the work, and that helps to inform what you do. And then as a manager—I manage a few people—those people now I try and instill the same [attitude of] don’t just think about you, think about how this affects other people. Think about how you can help this other team. So my team—we build one of the testing harnesses that are used to do the daily regression runs on ArcGIS Pro. We just built it because we needed it.
So you know ArcGIS Pro builds like eight times a day. We build the whole software eight times a day and we run our entire regression suite daily. All of the automated tests that we ever wrote are run every day – on every daily noon build, we run all of our tests. It’s thousands of tests in many different harnesses.
ND: On different graphical processors?
JW: Actually, the tests that we write are kind of [GPU] agnostic because our graphics engine—as long as it works with the API we are calling [DirectX or OpenGL] —it’ll work with any of those GPUs as a group.
We have tests that draw stuff and make sure it draws correctly. We have tests that convert MXDs and make sure they convert correctly. We have tests that click on things in the software and make sure the responses are correct. We have basically unit tests that test individual units in the software like the projection engine which, I mean, that’s like one of the most famous components of GIS is the PE.
So all those tests run every day on all of—basically like the whole ball of wax of ArcGIS Pro. And then components that are used across platforms like the PE, they have tests that run in different parts of the platform as well.
ND: How big is your team?
JW: The graphics engine team? We have nine developers and four product engineers.
And then there are 39 or so teams that work on Pro, different parts of the product like editing, or there’s the map authoring team which does all the stuff that deals with adding or moving layers and content management. There’s also a team that’s responsible for catalog view, the catalog pane. So all those teams work together to build Pro.
And every day all those teams’ tests run, they also make sure that the software is still working. If anything goes wrong, we investigate it. We correct it in the next build.
Anyway, what I was getting back to is, even though my team builds the graphics engine, we also help build the test infrastructure of these automated test harnesses that are used to test how the software draws, and how hit-testing works for selection, identify, and exporting. And then one of my product engineers is actually one of the QA leads on the release, so he’s also responsible overall for QA for all of the areas. So we have to have that sort of “global to the product”, or “global to the platform” perspective to do that job.
ND: One of my jobs was as a test engineer for Ordnance Survey. We were testing ArcGIS 9.1 and we were using the ArcServer & JTX system. That was 15 years ago. We had the trilateration tools, the bilateration tools. I had to go through every single tool one by one, a whole test case like you said. But it wasn’t automated back then, mostly manual.
JW: We still do that. actually. In Redlands at the bottom floor of building M, on the north corner, is a big open area that has a bunch of computers set up that are basically different configurations that meet our system requirements. They call it the holistic lab.
And the reason it’s called the holistic lab is because you test the software holistically. For every iteration and every release our own product engineers and people from tech support come down there and run through checklist tests like you said, where it’s like you click here, click there, and make sure it does its thing.
But they also can do freeform exploratory testing with their own data. So we’ll bring in our early adopter users. They’ll come and bring their data and their workflows and make sure that they can actually execute the things they need to be able to execute. If they have any problems—and every day that we do holistic testing which during certification is daily—they have a report that’s in a big shared document, and every team goes and checks it.
We do automated testing every day, we do manual testing almost every day, daily during release. We try to be as responsive as possible to all the inputs that we have, because there are thousands of users across the world using the software, it’s a huge responsibility to make sure that you don’t release an update that’ll break stuff.
ND: I think we spoke before because I had a graphical—the GPU issue where all of the sudden, out of the blue I started using the ArcGIS Pro one day and it was just like glitter. Just randomly. And I don’t know what caused it, but yeah, they did an update for the Pro and it started working again.
[JW: I believe we determined this was a GPU driver bug – once you updated the GPU driver from the manufacturer’s latest version it went away]
JW: And that’s why we release so many times. We release two, three times a year. So we want to be more responsive. We want to be “agile”—they call it—to those changing bugs, changing needs kind of stuff. And we also have good relationships with Nvidia and AMD, the primary GPU vendors. We try and cover all the bases.
Is there anything that you’d like to have added to ArcGIS Pro or to the Esri suite?
ND: Me personally? Tilt-shift.
JW: I’ve actually talked to one of our developers about how we could achieve that because we have an optic model that could be modified to do something like that…
