Wednesday, October 11, 2006

The Importance of Cohesion

I haven't gotten to post in a while, because I've been playing catch-up at work. We've lost a number of key people since this past summer, and the rest of us are rushing to pick up the loose ends. So I thought this would be a nice time to not only vent, but also write about the importance of cohesion.

Cohesion, as it applies to source code, is a measure of how well each individual command or statement works with related commands and statements, whether they be related by proximity or structurally within a method or procedure. Ideally, you want a natural flow of data from one statement to the next, with abrupt disconnects separated by method calls or other such syntax. Creating a variable that never gets used, or isn't used until much later in the code block, would be a bad example of cohesion.

Web scripting, usually being taught in the "Get 'er Done" methodology, is very susceptible to bad cohesion, particularly when implementing the beast known as the "Magic Scriptlet" anti-pattern, where the entirety of an application is coded in one file full of nested IF statements, POST variable switches, and function definitions. Concepts like includes help to reduce the complexity, but only when done properly. There is a tendency for programmers to discover modular programming concepts, and take them a bit overboard, to the point where following the execution of a script through multiple source files becomes a nightmare.

Cohesion also applies to teamwork. If one key member of a team hoards knowledge, whether it be project status, file locations, or design philosophies, it's not going to suit the overall performance of the team. It may feel like a personal job security measure, making yourself indispensable, but the downsides of having to keep track of your esoteric obfuscation methods will ultimately weigh down the project, and you end up shooting not only yourself, but all of your team members, in the foot.