There Isn’t Always an App for That

Have you ever had a brilliant idea? An idea so good that you thought, “That’s it! I wonder why nobody ever thought about this before!” At that moment, you are excited. You are about to create something cool, something new, something perhaps… revolutionary? But suddenly, the inevitable happens. You stumble on a reddit post where someone shares an idea similar to yours. Then, as if that weren’t bad enough, the most popular comment is from someone else saying “There’s an app for that.” If this resembles any part of your life, let me tell you a secret (spoiler alert!). There isn’t always an app for that.

Let me tell you how I reached this (not so brilliant) conclusion.

Motivation

At OutSystems, we don’t like bugs at all. So, for years we used a tool that categorized, prioritized, and grouped similar bugs together. Created many years ago, the tool grew organically. During this time, OutSystems has also grown a lot! More customers, more development teams, more features and suddenly, our tool told us in its special language, “Enough is enough!” Yes, it was time to say goodbye and start thinking about a new one.

Research

As soon as we decided it was time to modernize our tool, my instincts excitedly yelled, “Now is the time! Let’s put some money on the table and buy an app for that and let’s not reinvent the wheel.” But at OutSystems, my instincts have no say. I must use my brain to prove that my instincts are right.

First, I wrote down all our requirements so that I had the big picture for the search. The most important requirement was: we need to ensure that we are able to turn duplicate issues into a single issue. We mainly use the crash stack trace, and I quickly found some tools that aim to solve this problem.

And the Winner Is? Nobody

The majority of these tools work the same way. You indicate the programming language, and they offer you a library to be included in your software. After that, you just need a couple of lines in your code and you start receiving all the crashes in your own dashboard. Sounds easy right? And it is. But…

• Including a 3rd party library in our product is overkill: Our customers use OutSystems to build enterprise-grade apps, and we were weary of the code and licensing constraints we include in those apps. We have our own communication protocol to send crash reports back home, and for now we want to stick with that.
• The grouping mechanisms are not so great: As we scale our user base, it’s only natural that the same issue is reported multiple times. Most tools group issues by matching stack traces, but this is a naive approach to grouping. Most of our duplicate issues adhere to stack patterns, but they’re not identical. And frankly, we could get the same result with a simple query.
• The dashboards are pretty, but don’t go deep enough: Even after overcoming the grouping issue and filling some of the tools with all our data, we were disappointed with the dashboards. We were expecting that we could extract meaningful information from the data, but it was hard… I cannot say that the information wasn’t there… but I was expecting more. Something to help me answer questions like: How stable is my release? How does it compare with other releases?
• They didn’t offer Jira integration, Slack integration, support for several releases or data retention: These weren’t show stoppers. But, I feel that if you’re investing in a tool, it should offer everything you want, including things that will be important in the near future.

Disappointment

In short, I was disappointed. I didn’t understand why the tools I looked at didn’t cover all the bases. Why did they fall short for so many things? In our quest to find an app for that, were we expecting too much?

At this stage, I was flooded with many different feelings. In one hand, I had a bunch of tools and I could start tracking our bugs immediately with very low effort.

Low effort, but low return, too

On the other hand, those tools don’t meet our needs completely.

A little less presentation and a little more drill-down action is what’s needed here

I was feeling that I could do better. I could use OutSystems to help me. And, that’s what I did.

Going with OutSystems

First, I needed a way to connect to our data lake, Snowflake. Fortunately, OutSystems allows you to create database plugins with the database SDK, which enabled me to query Snowflake directly using an OutSystems application.

Second, I had to create a dashboard to show all the data from Snowflake. Well, with OutSystems you can use our Silk UI framework and create awesome dashboards with a great look and feel in a blink of an eye. So, after a couple of days of work, I had something like this:

This dashboard shows:

• All bugs grouped together by stack trace (only the first 7 lines)
• The number of duplicates per issue
• The number of users affected
• The number of versions affected

But, that’s not all:

We have a dashboard that shows these details of an issue:

• The distribution of bugs by time
• The distribution of bugs by version
• All the user feedback for a given issue

Manager Reaction

After all of this work, it was time to talk with my manager and tell him about my conclusions. I told him that after all of my tests, none of the tools available in the market seemed to be the right one for our use cases and in my opinion we should create our own tool. His reaction was something like this:

I know what he was feeling; creating our own tool entails some risks. We have to develop it, test it, maintain it, evolve it… and I was aware of this. But against facts there are no arguments. After showing how easy is to replicate the tools with OutSystems, in just a day or two, this was his reaction:

So There’s an App for That — So What?

These days it’s easy to believe that, for every problem, there’s an app for that. Everything has already been invented, and the space to innovate is thin. But here are some factors that fly in the face of “app for that” convention:

• Your own use case: The problem that you want to solve may have its own specificities. You may find a solution in the market to tackle your problem, but it will always feel like a shoe that’s a bit too small. If your problem is slightly different from the rest of the population, what good is it?
• You can do better: This is the most important factor. You can find many apps for the problem you want to solve. But you can do better. Don’t worry if you have an idea that is already on the market. That means nothing. Look at ride-sharing: taxis have existed since the 17th century, but Lyft decided to get into that market in a different way. Did that stop Uber? No, and now they’re the household name. So don’t give up; there’s always room for innovation.
• The world is changing: Every day our world changes, and it is changing fast. The conditions you have today will not be the same as what you’ll have tomorrow. Looking at the rides-sharing example again, in the 17th century nobody could create a mobile app to call for a ride. The same happened with my story. If I didn’t have a platform like OutSystems, maybe I would have had to stick with some other company’s app. But fortunately I didn’t.

I searched for a way to manage bugs, but I didn’t find an app for that. Fortunately, I had a low-code development platform to create it.