Using algorithmic techniques to solve non-tech problems

Victor da Hora

Published Oct 2, 2023

Hello there, fellows!

Since we are talking about problems, I think this article has caught you attention, right?

Problems are part of our life, in many forms, but let's straight to the point and talk about some real world corporate scenarios.

I'm going to share a couple of examples not related to programming itself, in order to represent how the foundation of two programming approaches can help you solve non-tech problems.

Dynamic programming

This technique relies on breaking down a big and complex problem into smaller and (consequently) simpler sub-problems and use this memory to progress and solve the following larger sub-problems. That's pretty much it. If you want to deep dive into this approach (I recommend it), I'm pretty sure the MIT guys will explain it way better than me, so please take a look at this reference if you want.

For the purpose of this article, let's focus on the foundation of this technique.

Article content — Fibonacci DP algorithm example. Source: in references

Ok, pretty cool, but how can I apply that in my work routine? Let's consider some examples.

Scenario:

You are pointed to work in this new project, in which consists on creating a push notification internal platform, so that all other teams could use it to contact users of your app. The initial purpose is to send general notifications like "You have unlocked a new achievement", "New feature available: digital account", and others. As more teams are aware of this project, the requirements get broader, to cover more needs and scenarios. At the end of the definitions, this is what the product team establish as requirements:

Batch notifications per user segmentation (middle market, micro-entrepreneur and others)
Response action buttons (2 at most) - example: accept and reject
Media attachment (images or PDFs)
Scheduled notifications
Two connection interfaces: REST API and events
Callbacks according to responses
Notifications history (database)

The company needs it up and running ASAP, so this is the proposed plan to tackle this challenge (as a reminder, this is an hypothetical scenario, this kind of things does not happen in real life...right?):

Jokes aside, this is not the most complex system in the world, but there's a lot of ground to cover here. Sending scheduled push notification with a PDF attached to a bunch of users based on segments and allowing 2 callback actions depending on the user response could be your complex problem. We don't know yet which database model should we use, how can we get users by segment and which storage and compression algorithm we'll use. How can we break it down into smaller problems?

Our base case here is to figure out how to send a simple text notification. After we solve this problem, we can iterate over this response and solve more complex requirements.

When you have a lot of questions to answer and you don't know where to get started, try solving the most simple fraction of the bigger problem. On top of this answer, you could iterate to achieve the complete solution.

Sometimes in software engineering, it could be easier to complete the cycle (coding, testing, publishing, maintaining) by launching smaller versions up until PROD rather than promote a big version, because the complexity will increase in all engineering phases (ref: working in small batches).

Side note: I don't consider a MVP (minimum viable product) breakdown as a dynamic programming approach, because the purpose of an MVP is achieving a low cost and quick solution, so that you could count on feedbacks to VALIDATE the solution, not to find an answer to a complex problem. In the MVP concept, your answer might change.

One other famous example is when your SCRUM team estimates a story in 21 points. Historically, when your team estimates more than 13 it means the problem is too complex and you have a lot of uncertainty. To solve that, you break it down into 2 stories - 13 and 8 points - so that you can tackle 1 smaller problem at time and use this memory to compose the whole solution. By the end of this process, you'll have the answer to your "21" complex problem.

Binary search

Here's the pattern: given an ordered flow, find the midpoint, validate the answer and move to the left or right side of the flow. Repeat the process until you find your answer. Again, if you want to deep dive into this topic, I liked this wikipedia definition.

Now let's consider the following examples in which we could apply it.

Scenario:

You are a support analyst in charge of all the systems responsible for the following steps of the order process (if any error happens, it will block the next step):

Your platform only present 2 statuses to the customers, and they are updated at the points represented in the flow (pending and shipped). All the other intermediate steps are not visible to your customers.

Recommended by LinkedIn

Why Programming Fundamentals Still Matter in the AI Era

Artemakis A. 3 months ago

What Does Source Code Stand For in the AI Era?

Ilya Lebedev 1 year ago

Beyond the "Vibe": Why Professional Engineering Still…

DAXAP 1 month ago

You've got a ticket from a very important customer in which its order has not been shipped yet according to the app, so the order is delayed. This angry user is in a call with customer support and it is saying that if we don't provide any clarity the order will be cancelled. How can we move faster in this case? We have a lot of steps to investigate what is causing the delay on shipment step...

Let's start at the midpoint of the pipeline process:

When you analyze the "Confirmed payment" step, you notice that the payment was properly confirmed... so it means all the initial steps are fine, otherwise the payment would not be ok.

So, let's move to the right side of the flow and find our next midpoint. Thankfully (or not) you've identified that the term was not generated, and that's why the order has not been shipped. After that, you do your tricks, and the user is able to validate the new status in the app. Yes, you did it so fast that the problem was solved.

I know this is a VERY SIMPLIFIED scenario, but if we think about it, we've taken 2 steps in our troubleshooting using this approach, instead of 5 steps if we had used a linear approach.

This approach applies when your problem follows an ordered sequence of steps or events. Starting from midpoints could be a shortcut so that you can move faster in your analysis.

Another very simple and daily situation: the transactions are not being registered in our database, so the data team has alerted your squad.

The midpoint between the client (frontend) and the backend app is this API gateway. Let's start from here:

It turns out that there's no request hitting the gateway coming from the frontend app, but if you manually send a ping test, it works. Let's ask our fellow frontend guy to take a look at the latest version of the app (yep, I'm a backend guy, disguise busted).

Conclusion

I wanted to show problem solving from a logical perspective, and try to explore situations in which these "thinking processes" could help you in your day-to-day work.

Keep in mind that they won't fit all the problems, every strategy works best given a specific scenario. Understanding the problem is the key, so that you can apply the best technique to solve it.

We could explore other algorithm techniques like 2 pointers (1 at the start and other at the end), so you could get help from a teammate to analyze in parallel 2 points of your pipeline process and move faster with the resolution (think of the same binary search examples). We could also explore divide & conquer approach, BFS/DFS (when your system journey/transaction splits into a lot of branches) and other famous algorithms to help us solve non-tech problems. Don't forget that as our last resort, we still have the brute force way...

See ya!