The Fisherman's Bend Analogy

I love analogies. Besides making me sound all knowledgeable and shit, they help explain web development concepts that people may have trouble understanding otherwise.

It's time for another analogy. In particular, a ropework analogy, in the vein of the Bowline Bend Analogy which I posted last year. As I may have mentioned previously, I spent a couple years out at sea in service to the Republic of Singapore Navy. So yes, I do know my way around a bale of rope.

The Fisherman's Bend 

Also known as the Anchor Bend, it is a common sailor's knot used to hitch a load to a post. Below is an illustration on how to tie it...

Make one round turn around a post.

Bring the end under the round turn, in a half-hitch.

Secure that with a second half-hitch. There's your Fisherman's Bend!

Round Turn and Two half-hitches 

The Fisherman's Bend is similar to another common sailor's knot, the Round Turn and Two Half-hitches.

Make one round turn around a post.

 

Secure that with a half-hitch.

End with a second half-hitch.

The Differences 

The Fisherman's Bend has the added security of having the first half-hitch interweaved with the initial round turn. It's also commonly accepted that of the two knots, the Fisherman's Bend is considerably more secure. Does it follow, then, that the Round Turn and Two half-hitches is obsolete and should be deprecated?

Not so.

Ideally, one should always use the more secure knot whenever possible. But situations are rarely ideal. The Fisherman's Bend is applicable when the load to be secured has not yet been applied; ie. the rope is not under strain while the knot is being tied. If the other end of the rope is hitched to a moving vessel, for example, attempting to tie the Fisherman's Bend may result in you losing your fingers. In such situations, one opts for the less secure but eminently more feasible Round Turn and Two Half-hitches.

What does this have to do with web development? 

Not just web development, but software development in general. There are some practices, such as the Goto statement, which are considered anathema to "proper" structured programming. A solid long-term solution is generally considered better than a quick dirty fix. But, as the Fisherman's Bend has shown us, best practices are situation-dependent. If a "proper" solution, in order to be implemented, would result in a downtime of about half an hour on a system that typically transacts millions of dollars per minute, what would management prefer - a proper solution or the quick dirty fix? You bet your sweet ass most of the time they'll opt for the latter.

A proper solution may result in better, more maintainable, more extensible, more everything software. But the value of that software is intangible, whereas the loss of several minutes of transaction time will be felt now. A software developer may feel differently of course - we're supposed to feel differently. Unfortunately, we don't make the rules. In these cases, immediate pragmatism wins out. There is little point in having a system that will reap benefits (in terms of cost savings) five years down the road, when a quick and dirty fix will take care of the problem now, with noticeably less downtime, and perhaps cause maintainability issues five years down the road.

Incidentally, this is also why people make loans which they have to pay interest on. Because waiting ten years to save the same amount of money makes absolutely zero sense when you consider inflation, and the fact that you need the money now, not ten years later.

The (b)end,
T___T