Close. The nub is that software is the only thing humans make that is going to change repeatedly and radically over its expected lifecycle. The only way to properly design software is to build into the very core a capability to change safely.

Every change will always bring a risk that a bug has been introduced. (I once fixed a bug in an application and another bug appeared. After I traced down the second bug, it turned out that the first bug had been compensating for it and my correct fix for it broke the application.) So, the proper discussion to have about bug-minimization is minimizing the chance of introducing bugs when making the inevitable changes.

When we discuss this in terms of structuring subroutines, we end up discussing the promotion of internal cohesion and avoidance of external coupling. Internal cohesion is summed up as "A subroutine should do one thing, one thing only, and that one thing well." External coupling is summed up as "A subroutine should only depend on the parameters it was passed in and the values that it and it alone controls." If you think about it in terms of your subroutines, those two things make perfect sense for improving maintainability.

Now, take the external coupling concept and extend it to the components of your application. We have, at a minimum, the user interface (UI), data storage (DS), and the stuff in the middle (APP). Your proposal would couple the UI to the DS. That's about as large an external coupling as you can get. It's not something you would do with your subroutines. Why would you do it with the basic chunks of your application? That is only guaranteeing that you will run into maintainability issues, as ptum has already discovered.