Grok Programming

Okay, so coupling in and of itself isn’t bad.  In fact, it would be hard to imagine a modern piece of software that has progressed beyond the toy stage that doesn’t have components meaningfully coupled together.  What I’m talking about is that insidious, chaotic, growing unnecessary coupling that happens so easily on a project.  Seriously, when you have a dozen folks working on a code base some crazy coupling is bound to creep in there.

Coupling is the AIDS of software development.  It won’t directly kill your project but it will make it easy for something else to kill it off.  As coupling rises the ability of the developers to simply understand the code, make orthogonal changes, and test the thing is reduced.  You can measure these symptoms as the length of time it takes to make a change, add a new feature, or fix a defect.  Eventually these problems get so bad that the “One Rewrite To Rule Them All” is ordered from CEO-ron from up on corporate Mount Doom or the whole thing is simply cancelled.  Both of those are generally thought of as Bad Things.

Can't get tighter coupling than this

Coupling shows up in various different forms in a project.  Most of these forms are defined really well on the Wikipedia article on Coupling so I won’t simply go over those again.  Just looking at that list it is easy to see why coupling can quickly get out of hand.  There are just so many ways that two pieces of software can be tied together.  Scary.  In my day-to-day activities I normally run into the various direct forms of coupling, sub-class coupling, and temporal coupling.  But one that I didn’t see on the Wikipedia list is behavioral coupling.

Behavioral coupling is a sub-form of Content Coupling but instead of accessing local data within the two pieces of code one module is restricted because of how another module is implemented (i.e. behaves).  Let me walk through an example to make myself clear.  Recently at the project I’m working on we needed to establish a web service to allow client systems to send us an XSD defined XML document and get a XSD defined XML document response.  On the surface that would seem to be an excellent example of low coupling.  Well, in discussions with the first client it came up that as things changed we wouldn’t be able to make XML elements optional because the client’s XML framework would freak out.  That boys and girls is behavioral coupling.  My code is now bounded in what it can do because of the way the client code acts.  We’ll come back to this story in a bit.

Behavioral coupling can happen within a single project too.  Imagine the case where using Hibernate to abstract away the database it still turns out that you have to deal with the database’s locking scheme.  That nice abstraction you’ve paid for in the development time of setting up Hibernate is now pooped away since you have to add code to manage the database component’s behavior.  Suppose you then switched to a real database and the locking scheme is different (i.e. works) you now have code to remove based on the new behavior of the database component.

So you’ve identified some behavioral coupling and need to do something about it.  Well, as I see it you have a few options:

1. Do what I did in the web services example and take the position of ” it is not my problem your XML framework sucks” and refuse the coupling.  I think of this as the simplest thing that could possibly work.
2. Assuming you can’t get away with #1 then you need to deal with it in the most modular away possible.  In the database example, using Hibernate or Spring interceptors or AOP to implement the database locking retry logic is a nice clean way to add that evil code and still be able to pull it out later if a real database is put in place.  The basic idea here is you put in place an “anti-corruption” layer that protects the innards of your software from the nasty, evil, baby eating coupling.
3. Broker a another way to do the work.

Honestly, #2 is going to happen more often than not.  Do you yourself a favor and start thinking about what you would do in the above database situation on your project.  That should lead you to a method for handling it in nearly all cases.  If nothing comes out of that exercise you’re probably in trouble.  But on the other hand don’t go on a crazy inquisition style hunt for coupling either (”all layers communicate with XML!”).  In the name of reducing coupling I’ve heard some really whacked out ideas.  I think the apex of the lunacy was the suggestion that only maps/dictionaries be used as types.  Yeah….

I wonder if there are any other forms of coupling not on the wikipedia list?  Got any coupling horror stories to share?