If you are working with integrations in a large software project, you are probably aware that the complexity of these projects often leads to additional errors that are harder to predict and troubleshoot. It’s very similar to the situation many people encounter when dealing with complex object models – it takes forever to dig through the mess to find the problems. As a result, object oriented developers have a set of heuristics for finding areas that are potentially problematic. These are typically referred to as “code smells”. In larger, more complex scenarios with multiple interacting services, there is also the concept of a “smell”. While a full list of these integration smells is far too large for a single episode, there are certain smells that are pretty easy to spot, even in a system that you just started working on. While these “smells” by themselves are necessarily a proof that something is actually a problem, they will quickly point you to locations where a problem might exist for further research. Like most heuristics, they need to be backed up with data, which is much easier to get from a few suspect locations instead of an entire ecosystem of services. There are dozens of possible integration smells that you will discover throughout your career. However, there are a small subset that you will consistently see and that you are likely to notice early in a new environment. While not necessarily a problem in themselves, these smells are simply things that should inspire you to investigate more thoroughly. It’s important to be able to recognize clear antipatterns, but it’s also important to be able to have a heuristic for things that might indicate that a particular antipattern is in use. In fact, the latter is even more useful, because it can also quickly point out quirks in a system’s architecture that are worth exploring. Links Join Us On Patreon Level Up Financial Planning