Using the abstractions of loose coupling at early stages of development tends to add more complexity than you gain, violate YAGNI, and give you the wrong things later. Unless you've already developed exactly that kind of software before you'll just make a lot of mistakes.<p>You have to go through a refactoring process at every stage if you want to achieve a big system with loose coupling.
Because it's cheaper, more efficient, gives you more control between components, may keep your code-base smaller, your engineers actually get something done, etc. Pretty much all the important stuff except long-term maintenance. Loose coupling, like anything else, is a trade-off you need to make. Not some absolutely right solution.
This is an interesting problem and as someone who's never been much good at writing big systems, I've given it some thought.<p>A system like Erlang helps here, I think, not because it is functional (and I say this as a functional programming advocate), but because it has a different metaphor for partitioning programs at the medium to large scale: processes.<p>With a process, you have to think about where you draw the "error boundaries". When a process fails, it fails and it is either restarted, or the calling process also fails and propagates the problem, or your code might simply report that the subsystem failed.<p>In the OO world, the main metaphor for decomposition of a problem is the class.<p>There are two pitfalls here, as I see it:<p>* The class metaphor is uniform enough such that it becomes difficult to decide where to draw the "error boundaries". This leads me (and others too, I suspect) to blur the small, medium and large scale interactions. Think of code that tries to deal with weird exceptions and interactions form a subsystem where, if this subsystem were a failing process (as in Erlang), the subsystem would have died and your code would have had to restart the process or give up,<p>* It's easy to share state. I am not yet sold on the idea that all shared state is evil (since I think there are problems that are easier to deal with when using shared memory), but I do think that the sharing of object references between different subsystems, in general, makes it much harder to have decoupled code.<p>It is possible to write OO code such that some classes are the equivalents of processes and where interactions with instances of those classes are treated as such (i.e. any exception coming from such an instance means that the instance must be terminated).<p>This need not entail too much extra work and benefit here is that one doesn't need to limit communication between "processes" to simple datastructures. And since the code uses the normal calling conventions, a debugger will work fine.<p>I do agree with everything that's been said here about refactoring though: for my part, I can't typically at the start of a project see how things should be decomposed.
This seems, I could have missed something, more to be about the loose coupling in Object Land. Not about loose coupling in software land.
Some sentences seems more or less taken out of context from any Haskell book (pure vs IO).
Some seem, again, taken out of context from the OTP Design principle.<p>More annoying is the fact that there is a code example of How Not Todo It but nowhere any How Todo it. I would have liked if the article had some indication on what direction the Author thought on some way to do loose coupling.
I have been the sole developer working on a enterprise web project (jboss/spring/hibernate) with extreme decoupling: 400k LOC and 48K of XML tying it together, rampant OOP and patterns du jour. First problem - too much code. Second problem - difficult to debug, because the flow of control often stopped at an interface. If the original developers had done decoupling as needed, the code would have been 50% smaller, more if done in something like Python, maybe 80% less.