Its all about decoupling...

Do you remember the charger we had for our Nokia 1100? What can you do with that one? You can charge a Nokia 1100 and may be, a few other Nokia phones.
What does the charger that come with, say my Moto G4 plus, do now? If I pull out the USB cable, I can use it to transfer data between my PC and tablet. My wife takes the plug and uses it to charge her Kindle.
Suddenly a charger that had the capability to charge one phone, with a simple change, was made into a multi-purpose gadget.
What made the difference?

• Division of labor and total ignorance - The changer was split into a plug and a USB cable. Plug that would feed the power to an USB cable, doesn’t care who is at the end of that cable. The cable that just transmits, doesn’t care if it is power or data. The parties at both ends decide what to transmit and how to consume.

• Smaller parts interact in well-defined interfaces - The plug converts the 220V AC current to what the USB expects, 5V DC and provides the right slot and pins for the USB to fit. You remove the plug and replace it with a PC, the PC’s USB port feeds 5V DC to the cable. The same happens on the other side, be it a mobile phone or a tablet or kindle. They either get charged or do data transfer.

That's a perfect example of a loosely coupled architecture. It tells how different components in the system has to work, without stepping on each other while enhancing on the functionality. I really would like to see software designed this way. If I am allowed to draw a parallel for software components, I would ask for the following properties.
Ignorant
The unit of software needs to be ignorant of the environment and the context it is working. It will do its one job, consistently and flawlessly. This might seem to be a stupid, but these software units are the workhorses of a bigger software system and it is very sensible for these to be in oblivion. The software components that will be sitting at a higher level of abstraction will use these workhorses based on context. That will be the one job of that higher-level component and it will do that one consistently and flawlessly. So, what will you get by being ignorant:
1.     Independent software unit. (Architect loves it)
2.     Parallel development. (Managers love it)
3.     Individually testable unit (Testers love it)
4.     Bugs are isolated and their radius of infection is small. (Maintainers love it)
5.     Easy to develop concurrent/multi-threaded systems. (Performance engineers love it)
6.     Developers love it, because they got to do all the above.
Adamant
The unit of software should be adamant about how should it communicate. There is only one well defined way to talk with the software component. Violating the contract will end up in an error, generally a specific error that says that the you have violated the contract. I love the statically typed languages specifically for the reason that most of these contract violations can be caught at compile time, but with the rise of dynamic languages, we rely on unit testing. As long as the clients know how to talk with the component and what the component can do, the component can be used in multiple ways. 
Challenges in writing such a piece of software...lets delve into that some other time..
Prod - Click Here