Trade offs in problem-solving with programming (and everywhere else)

Any tool or approach in programming, solves some amount X% of tasks, but brings other Y% of problems that we didn’t have before.

You want to optimise for solving the biggest X% of tasks, while getting the smallest Y% of problems from the tools that you use.

For example, in AMS Pilot we have a spreadsheet with filters, and the spreadsheet remembers the filters for the user, so when he navigates back and forth, he doesn’t have to adjust the filters on every page load.

This is how it looks like:

One day, a customer comes to me and asks to add a button - “Clear filters”. He further explains, that he opened the interface in the morning and wanted to start working, but was frustrated because the spreadsheet had remembered the filters adjusted from the yesterday and he had to reset manually all the filters by clicking on each one.

From that point of view, the “Clear filters” button is very useful. He could just clear all the filters in one click. But how often he has this task? Once a day in the morning. So it’s like 10% of the time he is using it (our users use the software all the time, they are full-time PPC managers).

But if we add the button, then all 100% of the users will see it 100% of the time. And even if we put it somewhere in a dropdown, it will still be a constant mental burden of complexity on the user. So it’s a very high cost to solve the task that only happens 10% of the time.

So, instead of a button, I suggested let’s make the filters be remembered only till the end of the day, and on the next day they will be reset automatically. This solves the task without the button. Win!

But it also introduces another problem that now some users cannot have filters remembered forever, but we thought about that and we know that in our specific use case this kind of task almost never occurs, so it’s the right trade off.

---

Always try to find the right trade off when solving tasks, so that you solve more problems, then you create. Often times the trade off is not immediately apparent, but it’s always there.