I'm the board technical advisor for my previous company, [bob-desk.com](https://bob-desk.fr/). As such, I deal with complex persisting issues brought to my attention by the team. This is why I chose this configuration, as it allows me to focus on the fun part and sharpens my problem-solving skills. Them: We have issues with notifications in our application. We don't like issues. Users don't like issues. We want to solve all our notifications problems. Me: They are all different problems. You can't solve them all in one go. You have to break them down. Them: Please take money and solve problem.  Me: Alright, I'll see what I can do. With the right combination of incentives (mostly being sick of having the same conversation over and over again, a sign I hadn't given the issue my full attention), I started playing around with the problem. I realized two things: 1. Business doesn't understand the problem because they don't see it. 2. Any idiot can write a bunch of conditions, so this is not really a code problem. The fact this is not a code problem doesn't mean this is not a problem that can be solved with engineering. The real problem is that operations got stuck in a loop along the way, where (1) business considers it to be an engineering problem ('all the business logic is in the code') and (2) engineers consider it to be a business problem ('there is no articulated business logic anywhere, the code is just a bunch of ad hoc arbitrary conditions'). To make things worse, the notification-sending logic got deeply intertwined with the rest of the logic. This is an ownership problem. Everybody is pointing fingers at everybody, while the general process over-relies on the understanding of any given individual, whatever their role. To give you an idea of the complexity we're dealing with, this is the high-level overview of the workflow that notifies users a ticket was created I managed to extract from our codebase. It still raises some questions.  Now that we have found the root of the matter, we can start thinking about solutions. The only way to give back ownership of the business logic to business is to give them tools to actually see it. This acts as the mirror of application logic, so that they can improve it. I don't wear makeup, but I'm pretty sure no one applies makeup to himself without a mirror. This way, engineers are back to working on the engine that supports the business logic instead of hot-patching day in and day out (it's not just a notification problem). So the tools have to be visual. In the past, we had tried: - Documenting with [Notion](https://notion.com). Things quickly become overly complicated, missing the point, and business itself couldn't understand its own documentation after a while - Documenting with [Excalidraw](https://excalidraw.com/). Business quickly got stuck trying to define the logic from scratch, having lost track of everything that had happened in the past years - Having engineers document the logic; however this documentation stops being updated after a while in a small, fast-paced startup, and business wouldn't even look at it or try to understand it. This time, inspired by [Knock](https://knock.app/)'s take on the subject[^1], I started playing around with AWS' [Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html). The visual builder made it an interesting communication tool, and this would nudge us to separate the notification-sending logic from the rest. Furthermore, this fits well in an event-driven architecture as you can easily trigger them from priority queues. I then realized they would have one other massive advantage. Because the visual builder, the documentation and the infrastructure are one and the same. It would be easy to give a read-only access to the system to business, so business would have nowhere to run from its logic ownership anymore, and engineers would have to make less hypotheses about what it is that they actually meant. This approach is non-blocking, as it allows us to treat one workflow at a time, making it the ideal candidate to untie this Gordian knot of ours. To be continued ! The point is, giant problems don't require giant solutions. Avoid solution symmetry: Tackle complexity with simplicity.[^2] Build better things. [^1]: We considered using Knock in the first place; however the volume of notifications sent by our application makes the pricing more than the business can afford. [^2]: For a somewhat opaque quote on the subject, here's Einstein's: "Everything should be made as simple as possible, but not simpler."