The first quote is an over-simplification that often does not hold in practice: one usually needs both. The exceptions are mostly trivial programs.
Depends, but not on the complexity of the application.
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.
Given all the code for the same set of applications, and you'd find it difficult, if not impossible, to predict what the business logic is across all the 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.
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.
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.