Recognizing and Responding to Brute Force

Software results from the efforts of many people. At its most basic level, eventually some programmer expresses intention to a computer in a language or mechanism that results in the desired goal being accomplished. Programming is the term, though coding may be more specific. And the choices made by the coders have profound impacts on the results.

As a developer and technical trainer for many decades I have acquired a “feel” for good coding when I see it. And when the code isn’t good, I have often struggled to express why.

There are excellent materials (blogs, books, classes, lectures, journals, etc.) on how to code. Some even cover how to code well. Most, though, handle the objective parts (such as language syntax and expression of logic) much better than the subjective parts.

What makes code good? Or, more useful to this discussion — what makes code bad?

This has been, for me, subjective for too long. There are specific issues which are quantifiable and can be expressed, if I only had the words. Here, then, is one of those issues with the words.

A symptom of accidental complexity that I refer to as brute force.

My purpose is to address one of the aspects I’ve been referring to when I say “I know it when I see it.”

Continue reading