This is, of course, a very common situation. Unexpected breakage is one of the chief indicators of degrading designs. Such breakage is due to couplings that tie modules together that you don't expect to interact with each other. Managing and minimizing those couplings are responsibilities that fall to every programmer. So, someone hasn't been doing their job!
There are quite a few principles that govern the dependencies between modules. One batch that I have a certain attachment to is called "SOLID". You can read about them in a paper called "Principles and Patterns" which you will find in the "Resources" section of cleancoder.com.
Even when you follow these principles assiduously, you will still sometimes experience unexpected breakage. And, of course, you don't find about this breakage until unit test time (if such a time exists). So the solution to that is to make unit test time come early. The earlier the better in fact.
That's why many of us use the discipline of test-driven-development (TDD) which you can find described in a paper entitled "The Bowling Game". This discipline moves unit test time to a very early time. It's so early, in fact, that it comes before you write any production code! When unit test time is that early, you find out about unexpected breakage very quickly.