We've been working on a embedded IoT many to many data pipeline and my past week's time has chasing down a gut feeling of "code smells" at the architectural level.

I've been wanting to extend the system, but have been running into way to many over-abstractions that did not sit well with me. With other team members also, there's a feeling of "how can this be better". FUD.

Sure, I could throw an LLM at it and it would create the right abstractions/de-abstrations and things would work. But that feels like putting band-aids on top of band-aids.

What were these code smells? It was a proliferation of these Rust micro traits which adjust a struct's interface to work with a variety of data channels.

Okay, but that's an observation and not yet a diagnosis.

I decided to pull out my hardcopy of Design Patterns which my mentor had me learn back in the day. (Do we still have mentors in a world of LLMs?)

Flipping through I found the diagnosis: Traits and over generalization had resulted in over "decoratorized" development.

The issues were concisely outlined in The Book:

" 1. A decorator and its component aren’t identical. A decorator acts as a transparent enclosure. But from an object identity point of view, a decorated component is not identical to the component itself. Hence you shouldn’t rely on object identity when you use decorators.

2. Lots of little objects. A design that uses Decorator often results in systems composed of lots of little objects that all look alike. The objects differ only in the way they are interconnected, not in their class or in the value of their variables. Although these systems are easy to customize by those who understand them, they can be hard to learn and debug."

Wow. These are the two smells I've been seeing:

1. A struct gets decorated via a trait impl in order to conform to an interface, but then the original struct information is lost.

2. So many structs, so many traits, so many generics.

So I have my diagnosis. Now the remediation. We need a central place to define data transformation and packet protocol between many heterogenous modules. Luckily I find the Mediator pattern later on in The Book.

"You can avoid these problems by encapsulating collective behavior in a separate mediator object. A mediator is responsible for controlling and coordinating the interactions of a group of objects. The mediator serves as an intermediary that keeps objects in the group from referring to each other explicitly. The objects only know the mediator, thereby reducing the number of interconnections."

So, today I've been drawing out the object diagram. Now I have clarity of the project in my head. Presented to the team. This cleared out the FUD for other as well...which is important to do as a team lead.

Some might say " Well, duh, just don't code bad in the first place. Design patterns are lame are over prescriptive."

Well, in the real world, especially with agile development, progress is made with architecture being a side thought or even an emergent property.

Sometimes that emergence is smelly.

Reflections on object oriented design patterns (2026)