The value of making business logic simple and accessible to new developers

I started my journey at AppsFlyer more than 4 years ago as an Automation Developer, today I am a Software Engineer in the OneLink squad.
My first task was to learn and rule our heaviest and most complicated service.

At the same time that I started my journey in development, my team also started a growth journey, and at some point the team had grown to the extent that a new team had to be formed. Now, the service that had been my responsibility had a dedicated team.
New developers joined, and it was necessary to teach them and get them involved in the team. After some training time, I suddenly realized the gap that developers experience in the face of this service (the Spaghetti Monster).

I quickly realized that my history and experience as an automation developer and QA, who’d worked around this service, is what helped me with my understanding. Usually one of the main expectations of a QA engineer is to see the full picture, to understand the business — well that’s nice and that was my path, but you can’t expect every new developer to have worked as a QA….

I tried to think of different ways to make our business logic accessible to others.
We started with teaching specific flows and doing different sessions on the most common flows. Indeed some developers felt better with their knowledge and gained some confidence, but once they hit a black hole that had never been discussed, the old unwanted feelings came back. What else can be done?

I want to share with you how we aim to make our business logic accessible to new developers. Before I can do that, let’s take a closer look at our business flow.

Basic example of a very common flow our clients experience

You’re surfing the web and see an advertisement for new headphones from your favorite brand, and only for today they are being sold at 20% off.
Once you click on it, we take you to your shopping app to a specific campaign page of those amazing headphones with a 20% discount.

What’s so complicated in our business?

We need to know how to respond to every request we receive from any user journey — and there’s a huge variety.
Every link of ours that is clicked somewhere around the world, from any source (app, browser, web view) must get the specific response that takes them to the correct destination. Usually you use the same apps and browsers, but around the world there are different groups of people with different usage and surfing habits.

Where can we experience problems and complications?

Each click we receive is being processed and treated based on the source, the platform, the various parameters and other settings of that specific account.
If you take my previous example, where our amazing headphones are sold on Amazon, we may see that they recently performed a study and found out that people do not use their mobile app. So they launched a campaign to encourage people to download their app.
Each user who downloads the app will receive 5$ for their first purchase through the app.
Now let’s focus on a two client scenario, one with an iOS device and the other with an Android device, both clicked on the advertisement and each of them is expecting to reach the relevant store for their platform.

From the service side, basically the same link is clicked but the source is different. Apart from the platform, we also have different browsers, i.e. Chrome browser on Android does not behave like Chrome on iOS.
As a result, even in this basic scenario, we are already splitting our logic and code into several different options, that usually ends up with as many different ifs or other conditions — and eventually you get your Spaghetti Monster. All that for one link that was clicked from two different platforms. Even more importantly, adding new logic to those flows can also be very complicated.

Back to our plan of making business logic accessible to all…

In the past few months we have been working on breaking this monolith into micro services, but it’s not new and not the most exciting part.

One of the benefits in planning a redesign and rewrite is the time we get for POC of new solutions, and one of them is the rules engine. We aim to use the rules engine mechanism to take our messy business logic and shed light on it… or in plain language, make it as clear as possible to our new developers, but also to the rest of the team.

What is a Rules Engine?

A rules engine is a piece of software that executes rules according to an algorithm. The rules engine combines a set of facts that are inserted into the system with its own rule set, to reach a conclusion of triggering one or several actions.

Here are some advantages of the rules engine in our case:

• Rules are very easy to read and code even by a non-technical person
• For frequently changing logic, we can easily update rules without writing a lot of code
• For complex code that contains many decision points, the rule engine can handle those parts much better because they use a consistent representation of business rules

What can we gain from this process?

We can see that by using the rules engine we aim to represent our messy code in a clean and easy way. If those rules have a clear definition of what they represent, if you can take a look and understand the business logic from a quick read, it’s a big win for us and more importantly for our new developer in the team.

Why is it important to make our service accessible?

We saw that the few developers that were able to learn and get familiar with the system are more independent in their daily tasks. They feel more secure to make big changes and work on critical and major issues.
Every one of us hopes to start their new job and be useful as soon as possible, this is just another way for us to make that happen.

Wrapping up

On a more personal note, from the beginning of the team we created around the service, it was my goal to make our logic clear and accessible. I still think of new ways I can help others approach this service and any other obstacle there might be.

Rules engine may be a great fit for us, but we shouldn’t forget that behind any solution we choose we must first choose great engineering as a concept, regardless of new or veteran developers. You don’t always have to love the business but, from what I learned in the team, you need to understand it to be able to move your skills into action.

I will continue to work and push towards removing dependencies on a single source of knowledge as much as I can and making our developers more confident in their work.