Recently working on my new mobile app Loopzzz, I encountered a small problem: my previous and next buttons which allowed to change audio tracks from the notification (and were working perfectly fine last time I tested them) were not functional any longer. Clicking on them had no effect whatsoever. After the first moments of doubt and denial, I was forced to admit there was a bug I needed to correct.

Sounds familiar? This happens every day, probably even several times an hour, in a developer’s life. New features, library updates = new bugs and unexpected side effects. This is why writing test scenarios and adopting TDD (Test-Driven Development) is so important: each time you change something it would be a mistake just testing what’s new; you want to make sure all the rest is still working.

Anyway, the rest wasn’t working in this case, as these two buttons had stopped working for some reason.

There was a bug, and my engineer mind went to debugging mode pretty fast. So in the next minutes, I started:

• Cleaning my project and updating my dependencies
• Uninstalling and reinstalling on my device
• Testing on a different device
• Adding print(« Name of the variable: $variableValue »); after each line of the relevant code

There was a problem to solve, and we were embracing the challenge.

And in this process, my engineer mind was happy: there was a problem to solve, and we were embracing the challenge.

But then my Product Owner mind stepped in.

This is a little bit the conversation they had in my head:

• Hi engineer! What are you doing?
• Hi! I’m solving a very complex problem.
• I see. And you like it?
• (With stars in eyes) Oh yes, I love it!
• Ok. And is it really useful to solve it?
• Of course!
• Are you sure?
• (Frowning a little) …
• Are these buttons absolutely central to using the app?
• (Frowning a little more) …
• Are people going to use them often?
• (With a sad face) …
• Or even notice if they are not here?
• … No, but it’s not right!
• I understand, but it has no value!

To my Product Owner mind, there was no value in solving this problem, because we could simply REMOVE it. The difference is huge: either spend your effort making the buttons work, or remove the buttons. Simply. Just like that. Because they are neither necessary nor desired by users, and will not be missed.

In the end, I went for a compromise: I hid the buttons and the associated code, accepting that my time would not be well spent on making them work, but letting myself the option of coming back later to find the solution to do so, if I have the chance.

This anecdote in my life as an independent app-maker made me realize not every problem needs to be solved. If it’s a possibility, one should consider removing the problem instead. I’ll try to keep that in mind for next times!