The volume of responses to my previous article about loose coupling was crazy. It wasn't just the volume - the responses were all over the place. Some of the themes of the comments really surprised me. Some readers vehemently agreed with me, other suggested that loose coupling isn't as big a deal as I made it out to be, and others suggested that there were other areas where I should have focused my attention.
By far, the heaviest volume of responses came from readers pointing out that too much loose coupling is a really bad thing as well. I don't disagree with this point - I even made this point in my post. However, as I replied to some of the authors, I WOULD LOVE TO BE STRUGGLING WITH TOO MUCH LOOSE COUPLING instead of being crippled by too little loose coupling. Making code more tightly coupled is ALWAYS, ALWAYS, ALWAYS easier than modifying tightly coupled code to be more loosely coupled. Besides, I just don't see nearly the incidence of overly loosely coupled code - it just isn't out there to the same degree as tightly coupled code. Not only that, but it just isn't as painful an experience to deal with.
It's an odd thing - my previous post about unit testing has been a big source of short term contract jobs for me. In this capacity, I have been called upon to help with all sorts of unit testing projects from helping to get unit testing kicked off for a project, help write unit tests, and just helping out with understanding how best to use unit tests to increase software quality. Many of the projects I see are nearly untestable, unstable, and difficult to change because of the high likelihood of breaking the project. I see people that are afraid to make changes to this sort of code, which makes it difficult to make needed changes to these projects. In the unit testing article mentioned above, I made the point that a homing beacon for poorly written software, especially tightly coupled software, is that it is difficult to unit test. Count on it.
Let me say it again: like everything else, loose coupling is a balancing act. A good architect will find his Zen for loose coupling and can be a good guide. In many cases, knowing how and when to loosely couple your software will be a mostly intuitive process for someone with years of experience. However, casting error on the side of more loose coupling than you might need will give you a more maintainable and easily tested system than by leaning toward more tight coupling.
Before moving on, I have to admit that I haven't given props to the contribution of cohesion in the role of maintainable software. I'm not going to try to explain it better or more concisely than the cohesion wiki: "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are." I have more to say about the role of cohesion in quality, but I will save that for another post.
Ideally, we will find a balance between the two extremes (loose coupling and tight coupling), but I'll take software that is too loosely coupled over software that is too tightly coupled - every time.
Resources:
- If you want a more elaborate analysis of cohesion, study the sample chapter from the book The Practical Guide to Structured Systems Design. The chapter does a good job illustrating the differences between the various forms of cohesion.
- Also, the book mentioned above, The Practical Guide to Structured Systems Design, is a great resource for architects looking to understand how to build maintainable software. It leans heavily toward an academic view of software (that's not all bad), and is very long-winded in parts.
- WWMFD? Martin Fowler is always a good source for software-related thoughts. He published an article way back in a 2001 issue of IEEE Software titled "Reducing Coupling". When in doubt, ask yourself What Would Martin Fowler Do?
- By "maintainable software" (I used this nebulous term above), I mean software that is relatively easy to understand, troubleshoot, modify, extend, and test. I include this definition here to direct you to a post by Jeremy Miller where he points out several qualities that make software difficult to work with. His post is well worth your time to read.
