This is only true because our tools for reading and exploring source code suck. I mean, we still work at the "unit level" of code (i.e. files and functions, classes, what have you). If our development environments let us viscerally experience the relationships of these units (a systemic perspective) we'd be in much better shape.
I disagree. The dream of getting a higher level picture of code is pervasive. E.g. UML was born to do exactly that. However, our modules usually do not compose cleanly, so you cannot visualize them as connected black boxes.
One common followup argument is that functional programming is great for this, because pure functions can be treated as black boxes. Sorry, but the problem is on the algorithmic/business logic level, which cannot be solved by the choice of programming language/paradigm.
Example: Remove data from one database and put it into another one, transactionally. At any point in time any other process must see the data in exactly one of the two databases. You can not merge the databases into one.
The problem with your example is requirements are not that strict. You don't need to move data from DB1 -> DB2 within a single clock cycle. And if you did some systems would think they saw the same data in both systems due to latency and caching etc. Thus the compromise of using a hidden intermediary (or blocking DB access) is not only reasonable but necessarily.
For stuff like this the absolute worst case is you update one or more legacy systems. But, that's just part of the cost / benefit / risk analysis.
UML? I said 'viscerally experience' not 'be forced to gouge your eyes out'.
I joke of course. But wouldn't you find it weird if two hundred years from now we were still writing and reading code like we are today? If that were the case, I'd say we had done a shit job of developing development.
