3 ms·

This analogy has some strength, but one of the most obvious complaints is as follows. Having everything go through one central bus (e.g. `bus.setItem` and `bus.

This analogy has some strength, but one of the most obvious complaints is as follows. Having everything go through one central bus (e.g. `bus.setItem` and `bus.getItem`) requires only two colors, one for the bus and one for everything else. But of course, that just hides all of the complexity. Nonetheless, focusing on reducing complexity and simplifying dependency graphs is good, mmkay.

Someone 9y ago
You can even get it down to one color by writing a big ball of mud (https://en.m.wikipedia.org/wiki/Big_ball_of_mud https://en.m.wikipedia.org/wiki/Big_ball_of_mud)
ballenf 9y ago
The complexity inside an interface should also be considered -- how the components of the 'bus' interact with each other with one connection to the outside world. If the 'bus' is simple enough to need few colors, then great. Same goes for the sibling comment regarding a ball of mud. It makes the analysis more complex but you should consider every global variable as connected to every other global in constructing the graph. Balls of mud, in my thinking, then need nearly as many colors as they have globals since every component theoretically interacts with every other. And when I mixed all the water colors as a kid, I was always disappointed to get a muddy color.
adrianratnapala 9y ago
Its important to remember that complexity matters at all levels of abstraction and you don't improve things by merely moving it from the level you are looking to one you are ignoring. Simplifying your depgraph by writing on big ball of mud means pushing the complexity down. Instead of a complex module graph, you have a complex dependency graph between variables/functions/whatever in your mudball. Oversimplify your individual modules and you complexify your module graph, or even your production infrastructure (one-line microservices anyone?). Forced to choose, I would prefer a mudball to dependency hell. But really I would like the complexity to be intelligently and somewhat evenly distributed to each level.

Someone 9y ago

You can even get it down to one color by writing a big ball of mud (https://en.m.wikipedia.org/wiki/Big_ball_of_mud https://en.m.wikipedia.org/wiki/Big_ball_of_mud)

ballenf 9y ago

The complexity inside an interface should also be considered -- how the components of the 'bus' interact with each other with one connection to the outside world. If the 'bus' is simple enough to need few colors, then great. Same goes for the sibling comment regarding a ball of mud. It makes the analysis more complex but you should consider every global variable as connected to every other global in constructing the graph. Balls of mud, in my thinking, then need nearly as many colors as they have globals since every component theoretically interacts with every other. And when I mixed all the water colors as a kid, I was always disappointed to get a muddy color.

adrianratnapala 9y ago

Its important to remember that complexity matters at all levels of abstraction and you don't improve things by merely moving it from the level you are looking to one you are ignoring. Simplifying your depgraph by writing on big ball of mud means pushing the complexity down. Instead of a complex module graph, you have a complex dependency graph between variables/functions/whatever in your mudball. Oversimplify your individual modules and you complexify your module graph, or even your production infrastructure (one-line microservices anyone?). Forced to choose, I would prefer a mudball to dependency hell. But really I would like the complexity to be intelligently and somewhat evenly distributed to each level.