Podcast: Break Things on Purpose | Elizabeth Lawler: Creating Maps for Code

For this episode of “Build Things on Purpose” we are joined by Elizabeth Lawler, founder of AppLand, the creators of AppMap. Elizabeth is here to chat about the challenges of building modern, complex software and the tool that she has built that serves as a “Google maps for code” for developers. AppMap is designed to show in a more visually driven way to help clarify, in real time, writing code. Elizabeth breaks down AppMap, why she choose to build it, the way it helps whole teams understand an application, navigating the open-source space, and more ways to build!

Episode Highlights

In this episode, we cover:

• Introduction (00:00)
• Elizabeth, AppLand, and AppMap (1:00)
• Why build AppMap (03:34)
• Being open-source (06:40)
• Building community  (08:50)
• Some tips on using AppMap (11:15)

Links:

• VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=appland.appmap
• JetBrains Marketplace: https://plugins.jetbrains.com/plugin/16701-appmap
• AppLand: https://appland.com

Transcript

Elizabeth: Whoa! [laugh]. That’s like getting a map of all of the Planet Earth with street directions for every single city, across all of the continents. You don’t need that; you just want to know how to get to the nearest 7/11, right? Like, so just start small. [laugh]. Don’t try and map your entire universe, galaxy, you know, out of the gate. [laugh].

Jason: Welcome to another episode of Build Things on Purpose, part of the Break Things on Purpose podcast. In our build episodes, we chat with the engineers and developers who create tools that help us build and operate modern applications. In this episode, Elizabeth Lawler joins us to chat about the challenges of building modern, complex software, and the tool that she’s built to help developers better understand where they are and where they’re going.

Jason: Today on the show, we have Elizabeth Lawler who’s the founder of a company called AppLand, they make a product called AppMap. Welcome to the show, Elizabeth.

Elizabeth: Thank you so much for having me, Jason.

Jason: Awesome. So, tell us a little bit more about AppLand and this product that you’ve built. What did you build?

Elizabeth: Sure. So, AppMap is a product that we’re building in the open. It’s a developer tool, so it’s free and open-source. And we call it Google Maps for code. You know, I think that there has been a movement in more assistive technologies being developed—or augmenting technologies being developed for developers, and with some of the new tools, we were looking to create a more visual and interactive experience for developers to understand the runtime of their code better when they code.

So, it’s interesting how a lot of the runtime of an application when you’re writing it or you’re actually crafting it is sort of in your imagination because it hasn’t yet been. [laugh]. And so, you know, we wanted to make that information apparent and push that kind of observability left so that people could see how things were going to work while they’re writing them.

Jason: I love that idea of seeing how things are working while you’re writing it because you’re so right. You know, when I write code, I have a vision in mind, and so, like, you mentally kind of scaffold out here are the pieces that I need and how they’ll fit together. And then as you write it, you naturally encounter issues, or things don’t work quite as you expect, and you tweak those. And sometimes that idea or the concept in your head gets a little fuzzy. So, having a tool that actually shows you in real-time seems like an extremely valuable tool.

Elizabeth: Thank you. Yes. And I think you’ve nailed how it’s not always the issue of dependency, it’s really the issue of dependent behavior. And that dependent behavior of other services or code you’re interacting with is the hardest thing to imagine while you’re writing because you’re also focusing on feature and functionality. So, it’s really a fun space to work in, and crafting out that data, thinking about what you would need to present, and then trying to create an engaging experience around that has been a really fun journey that the team has been on since 2020. We announced the project in 2021 in March—I think almost about this time last year—and we have over 13,000 users of AppMap now.

Jason: That’s incredible. So, you mentioned two things that I want to dive into. One is that it’s open-source, and then the second—and maybe we’ll start there—is why did you build this? Is this something that just was organic; you needed a tool for yourself, or… what was the birth of AppMap?

Elizabeth: Oh, I think that’s such a great question because I think it was—this is the third startup that I’ve been in, third project of this kind, building developer tooling. My previous company was a cybersecurity company; before that, I helped build applications in the healthcare sector. And before that, I worked in government and healthcare. And—also, again, building platforms and IT systems and applications as part of my work—and creating a common understanding of how software operates—works—understanding and communicating that effectively, and lowering that kind of cognitive load to get everybody on the same page is such a hard problem. I mean, when we didn’t all work from home, we had whiteboards [laugh] and we would get in the room and go through sprint review and describe how something was working and seeing if there was anything we could do to improve quality, performance, reliability, scalability, functionality before something shipped, and we did it as a group, in-person. And it’s very difficult to do that.

And even that method is not particularly effective because you’re dealing with whiteboards and people’s mental models and so we wanted to, first of all, create something objective that would show you really how things worked, and secondly, we wanted to lower the burden to have those conversations with yourself. Or, you know, kind of rubber ducky debugging when something’s not working, and also with the group. So, we created AppMaps as both interactive visualizations you could use to look at runtime, debug something, understand something better, but also something that could travel and help to make communication a lot easier. And that was the impetus, you know, just wanting to improve our own group understanding.

Jason: I love that notion of not just having the developer understand more, but that idea of yeah, we work in teams and we often have misalignment simply because people on different sides of the application look at things differently. And so this idea of, can we build a tool that not only helps an individual understand things, but gets everybody on the same page is fantastic.

Elizabeth: And also work in different layers of the application. For example, many observability tools are very highly focused on network, right? And sometimes the people who have the view of the problem, aren’t able to articulate it clearly or effectively or expeditiously enough to capture the attention of someone who needs to fix the problem. And so, you know, I think also having—we’ve blended a combination of pieces of information into AppMap, not only code, but also web services, data, I/O, and other elements and so that we can start to talk more effectively as groups.

Jason: That’s awesome. So, I think that collaboration leads into that second thing that I brought up that I think is really interesting is that this is an open-source project as well. And so—

Elizabeth: It is.

Jason: Tell me more about that. What’s the process? Because that’s always, I think, a challenge is this notion of we love open-source, but we’re also—we work for companies, we like to get paid. I like to get paid. [laugh]. So, how does that work out and what’s that look like as you’ve gone on this journey?

Elizabeth: Yeah. You know, I think we think quietly working are certainly looking for other fellow travelers who are interested in this space. We started by creating an open data framework—which AppMap is actually both the name of a code editor extension you can install and use to see the runtime of your code to understand issues and find a fix them faster, but it also is a data standard. And with that data standard, we’re really looking to work with other people. Because, you know, I think this type of information should be widely accessible for people and I think it should be available to understand.

I think, you know, awareness about your software environment is just kind of like a basic developer right. And so, [laugh] you know, the reason why we made the tools free, and the reason why we’ve made the data structure open-source is to be able to encourage people to get the kind of information that they need to do their job better. And by making our agents open-source, by making our clients open-source, it simply allows people to be able to find and adopt this kind of tooling to improve their own job performance. And so, you know, that was really kind of how we started and I think, ultimately, you know, there are opportunities to provide commercial products, and there will be some coming down the road, but at the moment, right now we’re really interested in working with the community and, you know, understanding their needs better.

Jason: That’s awesome. Number one, I love the embrace of, you know, when you’re in the startup land, there’s the advice, have never tried to monetize too early, right? Build something that’s useful that people enjoy and really value, and then it’ll naturally come. The other question that I had is, I’m assuming you eat your own dog food, slash drink your own champagne. So, I’m really curious, like, one of the problems that I’ve had in open-source is the onboarding of new community members, right? Software is complex, and so people often have troubles, and they’re like, how do I fix this? They file an issue on GitHub or whatever system you’re using, and there’s sometimes a notion with open-source of like, that’s a good thing that you called out. You can fix that because it’s open-source, but people are like, “I don’t know how.”

Elizabeth: Yeah.

Jason: Does AppMap actually help in enabling AppMap open-source contributors? Like, have you seen that?

Elizabeth: So, we’ve had issues filed. I would say that most of the fixes still come from us. If people wanted to run AppMap on AppMap to identify the bug, [laugh] that would be great, but it doesn’t really work that way. So, you know, for us at this time, most of it is community filed issues and that we are working to resolve. But I do think—and I will say—that we have actually used AppMap on open-source projects that we use, and we’ve found [laugh] flaws and bugs using AppMap with those projects, and have filed issues with them. [laugh].

Jason: That’s awesome. I love that. I mean, that’s what it means to be an open-source, right, and to use open-source is that notion of, like—

Elizabeth: Right.

Jason: Contribute wherever you can.

Elizabeth: Yeah. And if that’s the way, you know, we can contribute, you know—and I think similarly, I mean, our relationship to open-source is very strong. So, for example, you know, we came from the Ruby community and there’s lots of different kinds of open-source projects that are commonly used for things like security and authentication and we’ve done a lot of work in our own project to tag and label those commonly-used libraries so that they can be—when you pop open an AppMap everything is all beautiful and tagged and, you know, very nicely and neatly organized for you so you can find everything you’re looking for. Similarly, we’re working with open-source communities in Python and Java and now JavaScript to do the same thing, which is, you know, to make sure that important information, important commonly used libraries and tools are called out clearly.

Jason: So, as you’re adding more languages, you’re going to get more users. So, that brings me to our final question. And that’s, as you get all these new users, they probably need some guidance. So, if you were to give some users tips, right? Someone goes out there, like, “I want to use AppMap,” what’s some advice that you’d give them related to reliability? How can they get the best experience and build the best code using AppMap?

Elizabeth: Yes. So, this has actually been a key piece of feedback, I think, from the community for us, which is, we released this tool out to the world, and we said, “We’re going to bring here; we come with gifts of observability in your code editor.” And people have used it for all kinds of different projects: They’ve used it for refactoring projects, for debugging, for onboarding to code, for all of these different use cases, but one of the things that can be overwhelming is the amount of information that you get. And I think this is true of most kinds of observability tools; you kind of start with this wall of data, and you’re like, “Where am I going to start?”

And so my recommendation is that AppMap is best used when you have a targeted question in mind, not just kind of like, you know, “I’d like to understand how this new piece of the codebase works. I’ve shifted from Team A to Team B, and I need to onboard to it.” “I’d like to figure out why I’ve got a slow—you know, I’ve been told that we’ve got a slowdown. Is it my query? Is it my web service? What is it? I’d like to pinpoint, find, and fix the issue fast.”

One of the things that we’re doing now is starting to leverage the data in a more analytic way to begin to help people focus their attention. And that’s a new product that we’re going to be bringing out later this spring, and I’m very, very excited about it. But I think that’s the key, which is to start small, run a few test cases that are related to the area of code that you’re interested in if that’s an onboarding case, or look for areas of the code you can record or run test cases around that is related to the bug you have to fix. Because if you just run your whole test suite, you will generate a giant amount of data. Sometimes people generate, like, 10,000 AppMaps on the first pass through. And they’re like, “Whoa.” [laugh]. That’s like getting a map of all of the Planet Earth with street directions for every single city, across all of the continents. You don’t need that; you just want to know how to get to the nearest 7/11, right? Like, so just start small. [laugh]. Don’t try and map your entire universe, galaxy, you know, out of the gate. [laugh].

Jason: That’s fantastic advice, and it sounds very similar to what we advise at Gremlin for Chaos Engineering of starting small, starting very specific, really honing in on sort of a hypothesis, “What do I think will happen?” Or, “How do I think I understand things?” And really going from there?

Elizabeth: Yeah. It does, it focuses the mind to have a specific question as opposed to asking the universe what does it all mean?

Jason: Yeah. Well, thanks for being a guest on the show today. Before we go, where can people find AppMap if they’re interested in the tool, and they want to give it a try?

Elizabeth: So, we are located in the VS Code Marketplace if you use the VS Code editor, and we’re also located in the JetBrains Marketplace if you use any of the JetBrains tools.

Jason: Awesome. So yeah, for our VS Code and JetBrains users, go check that out. And if you’re interested in more about AppMap or AppLand, where can folks find more info about the company and maybe future announcements on the analysis tooling?

Elizabeth: That would be appland.com A-P-P-L-A-N-D dot C-O-M. And our dev docs are there, new tooling is announced there, and our community resources are there, so if anyone would like to participate in either helping us build out our data model, feedback on our language-specific plans or any of the tooling, we welcome contributors.

Jason: Awesome. Thanks again for sharing all of that info about AppMap and AppLand and how folks can continue to build more reliable software.

Elizabeth: Thank you for having me, Jason.

Jason: For links to all the information mentioned, visit our website at gremlin.com/podcast. If you liked this episode, subscribe to the Break Things on Purpose podcast on Spotify, Apple Podcasts, or your favorite podcast platform. Our theme song is called Battle of Pogs by Komiku and is available on loyaltyfreakmusic.com.