5 ms·
I’m not sure I buy the N² argument being made here. If we’re talking about communications between components within a software system then yes, for N component
by Chris_Newton 5y ago
I’m not sure I buy the N² argument being made here.
If we’re talking about communications between components within a software system then yes, for N components, there are roughly N² possible connections between them. But isn’t managing that complexity so we don’t connect everything to everything Software Design 101? If you design your system using structure like layers and pipelines then you’re effectively reducing that O(N²) connectedness to something more like O(N).
If we’re talking about having multiple choices for how to implement each component, such as when we have several libraries available plus the option of writing something from scratch, then given N choices for the first component and M choices for the second, there are NM possible connections we might have to implement. However, we probably only need one of those connections at any given time. If we need to modify or replace either implementation later, the most important thing for flexibility and future-proofing is that the data models and communications protocols are well specified, ideally following established standards that are likely to be followed by the other alternatives as well. Again, though, separating interface from implementation is Software Design 101.
So it seems to me that if either of those interpretations was intended, we’re talking about a problem that has largely been solved for a long time. Perhaps part of the reason it doesn’t always feel that way today is that there is so much emphasis on doing everything in “agile” fashion now. Sometimes that agility comes at the expense of establishing a well-considered software architecture and long-lived standards for interoperability. The “glue code” in software systems is where we pay any interest on those forms of technical debt, so while there will always be some need to marshal data around a large system with many components, there will be much, much more code needed if those forms of complexity aren’t well managed.
- keithnz 5y agocame in here to say the much the same. I also see much more that we get "pre glued" things that we then glue a few more things to. After 40ish years of coding, I think the amount of glue we use is about the same. It goes up and down a bit but there seems to be a natural limit to the complexity we can deal with.
- Chris_Newton 5y agoI also see much more that we get "pre glued" things that we then glue a few more things to. Do you mean other trends like increasing use of frameworks, scaffolding tools and “convention over configuration”? If so then I agree. One of the trade-offs being made there is immediate convenience against long-term flexibility. You get more functionality out-of-the-box with these kinds of tools, but the price is that they often don’t compose well.
- tobr 5y agoI don’t think either article is talking about every component of the system, just the things that do need to be aware of one another. Marcel Weihers original article says: > Glue is quadratic. If you have N features that interact with each other, you have O(N²) pieces of glue to get them to talk to each other. And this one says: > it’s “quadratic”: the glue code is proportional to the square of the number of things you need to glue Even the most well-designed architecture will not let you only glue things pairwise, and you don’t need a very high N to run into challenges with N^2.
- Chris_Newton 5y agoSorry, I still don’t buy it. How often do you really have a set of features that all need to interact directly with every other feature in a well-designed system, other than for small N like, say, an MVC triangle? Very often, a combination of better software design and standardisation can reduce the actual complexity of an implementation below the apparent complexity. For example, suppose you have a system where N components can produce a certain type of data and another M components can then consume that data. This might appear to be a system with N×M connections between components. However, these components don’t necessarily need to be directly glued together in the implementation. If you define a standard, canonical representation for this type of data, you only need each supplier to convert into that format and each consumer to convert from it, and now you have an N+M glue problem instead of the apparently N×M problem you started with.
- tobr 5y agoOf course you can do better than just blindly gluing everything onto everything. But as a general strategy you’re not really escaping N×M. The data format needs to support everything, and all of the consumers need to be adapted to any change in any producer. That’s your glue!
- Chris_Newton 5y agoIf your design is data-driven, and the data specification in turn comes from your requirements, why would you be updating your common, standardised data format just because any particular supplier or consumer of that data changed? The dependencies appear to be the wrong way around in that situation. If there is a material change in requirements, you update your data interchange standard accordingly, and then you still only need to adapt N+M producers and consumers to work with the updated standard. Either way, I still don’t see how we end up back with N×M. The consumers and suppliers are still communicating via the intermediary format and not all talking directly to each other.