3 ms·

> Given the data design of even the most complex set of applications that all interact with the same data, you can almost always predict what business logic is

by sidlls 4y ago

> Given the data design of even the most complex set of applications that all interact with the same data, you can almost always predict what business logic is supported by the set of applications. How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Without seeing something else, e.g., the code, a flowchart, or other diagrams it is impossible to predict what the program actually does. One can guess at bits and pieces of it, but not more. It’s like saying that given a table of numbers one can predict exactly what functions produced them.

lelanthran 4y ago
> How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Only if they're randomly named. > Without seeing something else, e.g., the code, a flowchart, or other diagrams it is impossible to predict what the program actually does. Seeing a table named "invoices", which has a column named "user_id" that is a foreign key for table "user" doesn't give you at least a few clues about the business logic there? Seriously, I want to see an example (choose an open source project) of a project where the data structures don't give any clue to what the business logic is. Once you go looking for that example, you'll see why the data structures are more revealing than looking at the code.
- sidlls 4y ago
  It gives clues, but it doesn't tell the whole story. It certainly isn't enough to do anything other than make a pure guess at what the application actually does and more importantly how it does it.
  - lelanthran 4y ago
    > It gives clues, but it doesn't tell the whole story. It certainly isn't enough to do anything other than make a pure guess at what the application actually does and more importantly how it does it. I'm not claiming that it will tell the whole story; I am claiming that it tells so much more of the story than the code, that you may as well just not look at the code if you have the data structures. OTOH, if you look at only the code and not the data structures, you'll have so little of the story that you cannot make any change without risk of breaking some other piece of logic. There's just no comparison between "The code tells us what the applications should do" and "The data tells us what the applications should do". If you can find any examples where it is faster to determine what business logic is supported by the application by examining code (as opposed to being faster to determine what business logic is supported by examining the data structures), I'd very much like to see that.

by sidlls 4y ago

lelanthran 4y ago

> How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Only if they're randomly named. > Without seeing something else, e.g., the code, a flowchart, or other diagrams it is impossible to predict what the program actually does. Seeing a table named "invoices", which has a column named "user_id" that is a foreign key for table "user" doesn't give you at least a few clues about the business logic there? Seriously, I want to see an example (choose an open source project) of a project where the data structures don't give any clue to what the business logic is. Once you go looking for that example, you'll see why the data structures are more revealing than looking at the code.

sidlls 4y ago
It gives clues, but it doesn't tell the whole story. It certainly isn't enough to do anything other than make a pure guess at what the application actually does and more importantly how it does it.
- lelanthran 4y ago
  > It gives clues, but it doesn't tell the whole story. It certainly isn't enough to do anything other than make a pure guess at what the application actually does and more importantly how it does it. I'm not claiming that it will tell the whole story; I am claiming that it tells so much more of the story than the code, that you may as well just not look at the code if you have the data structures. OTOH, if you look at only the code and not the data structures, you'll have so little of the story that you cannot make any change without risk of breaking some other piece of logic. There's just no comparison between "The code tells us what the applications should do" and "The data tells us what the applications should do". If you can find any examples where it is faster to determine what business logic is supported by the application by examining code (as opposed to being faster to determine what business logic is supported by examining the data structures), I'd very much like to see that.