Monday, October 13, 2008

Improving time-to-market with loose coupling and high cohesion

What a gripping title. I considered others such as Cohesion is the Viagra of loose couples, and Get High with Cohesion - Get the Low-down with coupling. My daughter is much better at the marketing side of life, yet (amazingly) she's not all that interested in coupling and cohesion. Go figure.

Eleanor Roosevelt once said, "The things you refuse to meet today always come back at you later on, usually under circumstances which make the decision twice as difficult as it originally was." This is never more true than in programming where the mistakes made early on will always require you to revisit them later - often at a higher price.

Briefly stated, loose coupling leads to a condition where changes in one module (object, component, procedure, class) of an application seldom cause changes to others. While various modules of an application may (and need) to communicate with each other through function calls, methods, APIs, and interfaces, the fact that a programmer has to change one module should not necessitate changes to another.

I've heard some noob (newbies) claim that loose coupling is a red herring. They'll cite the example of adding a new data item to the user interface (such as a web page). This would require changes to the web page, the servlet, the communication objects, the SQL, and the database. Well yes and no. A user request such as this may require all of those changes, but the changes are the result of the user request, not poorly designed code. In a well designed system, none of the function/method calls would need to be changed and the APIs would remain the same. What we mean by loose coupling is that changes to the internals of one module should not cause changes to the internals of another.

Cohesion is a bit different and deals with object responsibility. If an application has an object that represents a Bank Teller, that object should be highly cohesive in that it performs only those tasks associated with a teller. For instance, you would not expect to see a method call such as: Teller.openBranch() as a means of preparing the system to do business. Possibly the "openBranch" method would be appropriate for the BranchManager object. You'll sometimes hear the phrase misplaced responsibility used between developers discussing an application's cohesion.

A loosely coupled system is one where it is easy to make changes in modules of the code without having to make changes in others. A highly cohesive system is one in which the purpose/responsibilities of the various modules are clearly and cleanly delineated.

So what on our little green Earth does any of this have to do with improving time-to-market? I've seen statistics that indicate 70% of an application's life is spent in maintenance mode; after the initial development. We have applications that are over 20 years old where the original development spanned less than 18 months. These applications have spent 92% of their life in maintenance mode - and trust me, these apps have been constantly updated.

Recognizing that applications undergo changes, and exist for most of their life in maintenance mode, then asking how we can facilitate changes to reduce the time and costs associated with those changes is an important question. Enter coupling and cohesion.

Applications with loose coupling allow for changes in one module/class/object/procedure to occur without necessitating changes in another. Highly coupled applications (high = bad) often cause programmers, users, and customers headaches when changes in one part of the code cause unintended problems in another. The real problem, of course, with highly coupled code is that there are no warning signs, no breadcrumbs, or indicators that the change a programmer is about to make is going to cause an issue somewhere else. So, you are left with each and every change requiring substantial desk checking and regressing testing to certify the application. This takes time.

Highly cohesive applications enable developers to quickly determine where functions are (for modifications) and where they ought to be (for new function). Additionally, highly cohesive systems tend to also be loosely coupled. I'll not go into the math of this here, but experience shows that coupling and cohesion tent to travel together for both good and bad (i.e. high coupling (bad) tends to be found with low cohesion (also bad)). Low cohesion (bad) makes programmers work harder to identify problems in the code and/or add new function. This takes time.

As directors, managers, and developers we should strive for applications which are loosely coupled and have high cohesion for many reasons; the primary one being a reduction in time-to-market for modifications, bug fixes, and enhancements.

No comments:

Post a Comment

Follow by Email