2 ms·

If 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

If 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.

tobr 5y ago
But this is a “let them eat cake” argument. It doesn’t matter that there are strategies to mitigate the problem. Most parts of most systems don’t communicate through a standardized data format, but an ad-hoc interface that addresses the immediate needs of the current requirements.
- Chris_Newton 5y ago
  Most parts of most systems don’t communicate through a standardized data format, but an ad-hoc interface that addresses the immediate needs of the current requirements. That’s actually a very big claim, and I don’t know how we could possibly test it. Counterexamples are easy to find, however. Consider that you’re reading this in a web browser that is communicating with a web server hosting HN. That communication, as indeed the article itself observes, happens via several standard protocols layered atop one another. I didn’t really understand the argument the article made at that point that this doesn’t solve the N² problem because it doesn’t take into account the application data at the top layer, as in practice almost everything sent over the Internet is also using standard application protocols like HTTP or SMTP as well. This has enabled literally billions of devices to communicate many types of data effectively on a global scale with a wide variety of software implementations on both ends of each connection, so IMHO it’s a pretty convincing example of the benefits of effective standardisation. Of course it’s still true that some software systems have connections all over the place using ad-hoc data formats and protocols, but often that is simply bad design. Software design is a skill and like any other skill you don’t get good at it until you’ve worked on it for a while. My argument here, in a nutshell, is that if you learn good design skills and make the effort to establish good software architecture and useful standards for a project, very often the N² problem described in the article isn’t such a problem after all.

tobr 5y ago

But this is a “let them eat cake” argument. It doesn’t matter that there are strategies to mitigate the problem. Most parts of most systems don’t communicate through a standardized data format, but an ad-hoc interface that addresses the immediate needs of the current requirements.

Chris_Newton 5y ago
Most parts of most systems don’t communicate through a standardized data format, but an ad-hoc interface that addresses the immediate needs of the current requirements. That’s actually a very big claim, and I don’t know how we could possibly test it. Counterexamples are easy to find, however. Consider that you’re reading this in a web browser that is communicating with a web server hosting HN. That communication, as indeed the article itself observes, happens via several standard protocols layered atop one another. I didn’t really understand the argument the article made at that point that this doesn’t solve the N² problem because it doesn’t take into account the application data at the top layer, as in practice almost everything sent over the Internet is also using standard application protocols like HTTP or SMTP as well. This has enabled literally billions of devices to communicate many types of data effectively on a global scale with a wide variety of software implementations on both ends of each connection, so IMHO it’s a pretty convincing example of the benefits of effective standardisation. Of course it’s still true that some software systems have connections all over the place using ad-hoc data formats and protocols, but often that is simply bad design. Software design is a skill and like any other skill you don’t get good at it until you’ve worked on it for a while. My argument here, in a nutshell, is that if you learn good design skills and make the effort to establish good software architecture and useful standards for a project, very often the N² problem described in the article isn’t such a problem after all.