Old office buildings used to be designed much like homes: stone walls, plastered ceilings, wooden floorboards. Spaces to fill with furniture and people. Flexibility and change were not part of the plan.
That changed in the middle of the last century, with things like raised floors and suspended ceilings becoming the norm. This allows lighting, electrical, and telecomms services to be moved around to where they're needed. Office buildings also tend to be designed such that the internal walls are non-structural, so they can also be taken down and rebuilt easily without affecting the overall integrity of the building.
In this example, different parts of a building's function are insulated from each other, so that changes can be made to one element without affecting others.
The same thinking is useful in software. Different functions in an application should be insulated from each other.
This kind of insulation shows up in a number of techniques. Subroutines and modular programming were early examples, followed by message queues, client server, and object orientation. These are not mutually exclusive, just different tools to divide systems up in different ways.
To be effective, this kind of thinking has to be introduced early on in the design process, and like any tool you have to know how to use it. A poorly-designed object-oriented system can be just as much of a maintenance nightmare as early sixties spaghetti code.
Whatever the technique, the objectives of good insulation are pretty much the same. Each part of the system has its own special job to do and doesn't need to worry about how any other part works. This breaks the coding work down into bite-sized chunks, each with clear objectives. This not only makes the coding easier, it makes everything easier to test. It also means you can make changes to a function and be confident that your changes will not have unintended consequences elsewhere.
Imagine the chaos at home if the simple act of plugging in the vacuum cleaner caused the toilets to stop flushing. Laughable? Maybe, but that is pretty much the state many poorly-insulated software applications find themselves in.