OutSystemsDev Zone

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.

Smartphone outline graphic - yes, there's 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.

app for that bug tools

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.

an app for that low return

Low effort, but low return, too.

 

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

 

an app for that other tool dashboard

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:

an app for that issues dashboard

 This dashboard shows: 

  • All bugs grouped together by stack strace (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:

an app for that detail issue dashboard

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:

 

 an app for that manager reaction 2

 

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 Uber 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.

 

 

About the author

Gonçalo Tavares

A software engineer for OutSystems, Gonçalo Tavares is a firm believer in using his brain and doing research to make sure the OutSystems low-code platform is the best it can be.

Comments

João Espada

Awesome read! 🙂

Pedro Rodrigues

Waiting for the beerware version :).

Very nice read, as I share the feeling. Searching for, and selecting a proper ticketing system felt the same exact way, if I pay, this thing as to tackle every requirement, properly. And when you set yourself to such standards, more often than not, there is no app for that.

There hundreds of ticketing systems available, some cheap, some expensive, some free, none able to fulfill my requirements, at least not in its entirety. And my conclusion, at the time, was as follows.

If you set both feet on earth and compile a proper requirements list, you’ll find there are apps capable of tackling all of them, but no single app capable of tackling every single one. And thats the point, its not that there isn’t an app for that, in fact there are many, but no way for them to colaborate. Or, you may argue, there is no app configurable enough to be able to fulfill your needs.

Some years after that, we are still conviced that our email server was able to tackle the challenge and we would have the same amount of difficulties (just diferent) that we would with any other software. Maybe our budget helped to reach this conclusion, the fact is thought we paid the mail server before and we paid it to this day.

It may also be, that our expectation of comercially viable technology is ridiculous. But that would also mean our requirements whore ridiculous.

Google Calendar is spectacular, at telling me that I’m late even before I left and there is still 40 min to go before my appointment schedule. Its some sort of magic! Actually its not, is just a very clever AI, looking at god knows what, and telling me that my usual, not very efficient, route choice may not be able to get me there in time. But he does not know I getting an Uber there, and so it simply does not care how long an Uber ride to there will take. Is there a Googler reading?

And that, I think, sums up the current state of affairs. But hopefully, someone, may I even say at OutSystems, will develop an app to fix that.

Anyway, looks great, and looks like I would find great use to it. Maybe that beerware thing…

Are you actually using that app to manage it’s bugs?

Leave Your Comment