Trace is one of the newer additions to Bitrise — we wanted to extend the development experience for users by creating a mobile-focused performance monitoring solution that can be accessed from their trusty CI. In this interview, we talk all things mobile performance monitoring with Trace Product Manager, Colin Hemmings. Let's dive in!
First thing first: what is Trace?
Trace is monitoring made for mobile, helping you detect issues, assess the impact and trace the cause. Trace is a part of Bitrise, working seamlessly with the whole product.
Colin, you are the Senior Product Manager of Trace now. What did you do before joining Bitrise?
We were a startup called Outlyer, and it was a service monitoring how apps are performing from the server perspective. We were acquired by Bitrise 2 years ago, when the team was around 20 people and finally 9 of them joined Bitrise. Mostly developers, and one sales person.
The goal was to build out a similar offering but for mobile apps. So in the past 2 years it's been still tracking how things are performing, but it's gone from the back-end component to the mobile.
What is the difference between the two?
The complexity is different. It's hard to say more or less complicated or harder or easier. It's different. Having had some experience with mobile before this helped, but it was quite enlightening to experience the difference in the problem space for mobile versus a traditional server back end monitoring.
The volume is a lot bigger now. When you're monitoring servers, you can have hundreds and thousands of servers, if you're a large company. But when you're building even a small mobile app, that could still be deployed to thousands or millions of users. And that means we can have a ton more data coming back in.
Also, you've got a lot less control over the environment, for example, the different types of mobile devices your app can be running on... and these mobile devices move around, so they can have different network and connectivity issues and you have to provide different insights into all that data.
What was the best thing about developing Trace?
Now is an interesting time for mobile, but I think when we first started building server-side monitoring, that was interesting too. (laughs)
Especially from a monitoring perspective, you can see that mobile development teams are starting to face the problems that we were facing on the server side and all the challenges that come with that. So it's definitely an interesting time for monitoring on the mobile side, and the really hard problems around anomaly detection and machine learning. And it’s not just capturing that there is a problem but it’s finding ‘the needle in the haystack’ problems that are hard to reproduce, and also abstracting back the root causes of those. And I think that the interesting challenges are just starting to hit us.
What was your greatest learning in the past two years?
That mobile developers are people too. (laughs) And I don’t mean it as derogatory, but I’m more sympathetic towards mobile developers now. I’m appreciating the challenges of building mobile applications.
I had some experience, but working with mobile development teams made me understand the unique set of challenges that they have to go through. The development process for mobile seems incredibly painful compared to anything else I've done prior to this.
And not only are the challenges different, I think that some of the tooling around mobile is kind of behind where it should be.
So the goal is to bring mobile monitoring forward, into the present?
The goal is to remove the guesswork and there's not great tooling around for that. At the moment, understanding where the application has problems is hard: there's a bunch of tooling that helps development teams see where critical issues are. But in addition to these, the more nuanced issues maybe don't cause the application to have fatal errors, and they are still providing a poor experience for a certain set of their end users.
When you find that there is a problem, knowing where the problem is in your application, you have to jump through quite a lot of hoops to reproduce the issue and get to that root cause. And I think we can do a better job of providing that insight and then allowing mobile devs to focus on building their application and adding value.
What are the other monitoring tools like?
There's a lot of monitoring tools, and there's kind of two camps really. Very few of them are focused on mobile use cases. And because monitoring is a big domain, those that do focus on the mobile use cases, typically only focus on a small segment of that: there’s crash reporting, and performance monitoring, there's logs and user insights. They don't cover enough of the different areas of monitoring to give you that insight and that context around how things are going. So they'll provide crash reports, for example, but then you don’t see how this is affecting the user journey. So it's not broadened and focused enough... It only seems to be a contradiction, it isn’t.
And then there are tools that cover that entire domain, but these are traditionally focused on server side, and mobile is added almost as an afterthought or an extension, a checkbox as part of their portfolio of tooling.
So when you joined, did you instantly start working on Trace? How clear was what you wanted to achieve?
There's always been a clear, strong vision for Bitrise around the development lifecycle for building mobile apps. Obviously, CI/CD is fundamental to that process, it orchestrates the different parts of those processes, but developers still need to go through the coding, the testing, the deployment, monitoring, to understand how it's performing, and then feeding that back in. So that vision has always been completely clear.
When we've started building out the monitoring aspect, we wanted to build Trace with the users in mind, so that we can fulfill the user needs. So since day one, we've always been working with the user base to understand what's important to them now, and what's going to be important to them in the future. This is a tough challenge, because users don't really know what they want until they see it, like ‘the faster horses versus an automobile’ case.
Can you give an example of how the initial scope changed?
So we've been trying to discover and understand what users are trying to do and then build iterations of the product and test that with them. The first iteration was purely focused on performance monitoring, and we quickly realized that we need to cover crash reporting and provide that holistic solution around their application.
From day one, we've had users testing the product in various forms, from wireframes, to functioning prototypes to alpha and beta versions of the product. And we're going to continue to do that as we go forward. You know, we’ll never get to a point where we have solved all the problems, because the technology is always evolving and getting more complicated. And we've got a healthy roadmap of things we want to add into Trace. So we'll always be working with users to make sure we're not building things in isolation. We're building things that are going to be valuable.
Webinar: Take monitoring of your mobile apps to the next level
Join Colin and industry experts Antoine van der Lee, Marina Gornostaeva, and Bruno Rocha in our upcoming webinar, where we'll discuss different approaches, best practices, and the ever-changing world of mobile observability and data privacy.
