Loose Coupling is good. Tight coupling is bad. A familiar mantra for any system designer. The problem with loose coupling is that it is incredibly fragile. Without constant care and attention it can easily whither and die. The challenge that the architect often faces is justifying what can often be a nebulous concept to a project manager who has a deadline to hit. So what exactly is loose coupling and how can the architect stand up for it?

To help get some clarity it is a little easier to talk about the opposite effect. Tight coupling is all too familiar to anyone who has worked in a legacy environment; the effects are all too evident. Systems that can’t be changed because it will break something else. Database schemas which can’t be updated because someone has knocked up a quick query rather than use the agreed interface. Changes that take so long and cost so much to implement that there is no business case for carrying them out despite them clearly being the right thing to do. Sound familiar? Well that is tight coupling in action.

In the next post we’ll look at an example to see if we can understand what happens with real-world systems.