So I wrote an application that loads data from a 3rd party API. It allows the user to enter a record locator number and pull it up. By design, the value can be a partial match and it will pull up the record still.

The first API call I make only took 2-3 seconds, so I didn't see an issue as it's loading most of the data the app needs. I keep the filters/fields as they are and move on.

Fast forward 6 months. The user is complaining that the records are taking 30-45 seconds to load. Sure enough, load times are terrible. I've made lots of changes to what fields I'm loading through the API, and I'm calling several additional APIs, so I start pulling pieces of code out to see if anything improves. They all barely make any difference--still 30+ second load times. I end up removing everything except the first API call I developed that was taking 2-3 seconds before. Still taking 30+ seconds.

The 3rd party API allows you to filter using "starts with" or "contains". I used "contains" initially and had no issue, but I decided to try "starts with" since it should fit most use cases.

Load time is less than one second. I add back everything else. Load time is just over a second.

It seems that the 3rd party updated the API and multiplied load times by 10 when using that particular filter. I spent almost an hour on this since the platform doesn't support performance or debugging tools very well, and it all came down to a one line fix.

When I had to choose a service, I chose bitbucket. Now the other two are getting flamed. Seems like I chose right. But in the end who knows what is good and what is bad. Peaches are delicious. Winter is coming. And I definitely don't care.

So we have this really annoying bug in our system that customers keep complaining about. I've explained in detail, multiple times, why the part they think is a bug is not a bug and the workaround they keep asking me to apply doesn't make sense, won't fix the issue, and won't even stick (the system will notice that the record they want me to delete has been removed and it will repopulate itself, by design).

I've told them what we need to do as an actual workaround (change a field on the record) and what we need to do to properly fix the bug (change the default value on the record and give proper controls to change this value through the UI). We've had this conversation at least three times now over a period of several months. There is a user story in the backlog to apply the actual fix, but it just keeps getting deprioritized because these people don't care about bug fixes, only new features, new projects, new new new, shiny shiny new.

Today another developer received yet another report of this bug, and offered the suggested workaround of deleting the record. The nontechnical manager pings everyone to let them know that the correct workaround is to delete the record and to thank the other developer for his amazing detective work. I ping the developer in a private channel to let him know why this workaround doesn't work, and he brushes it off, saying that it's not an issue in this case because nobody will ever try to access the record (which is what would trigger it being regenerated).

A couple hours later, we get a report from support that one of the deleted records has been regenerated, and people are complaining about it.

🙄🙄🙄🙄🙄🙄🙄🙄🙄🙄🙄