The hackability of simplicity

Thu, Apr 2, 2020 ❝How the original 'hacks' are made possible by simplicity.❞

Contents

In ‘The definition of simplicity’ we looked at how we may define simplicity in terms of 3 properties that help to evaluate the simplicity of a solution. While writing the blog post, I realized that actually simplicity may be the determining characteristic for a solution to be used as what we call a “hack”. That is, the original term “hack”, referring to a clever solution / workaround using parts not originally intended for that purpose.

Benefits of the “simple” solution

Let’s have a quick look at the properties of simplicity:

Specialized meaning that the requirements are as narrowly as possible defined to the problem that needs to be solved. Hence no over-asking for problem variations that are irrelevant in the particular case.
Unoptimized meaning there are no hidden assumptions in either the problem domain or the solution domain that are critical for the solution to work. Hence the solution is not tied to a specific context.
Reduced meaning the most succinct way of expressing the solution. Hence the most direct, comprehensible, “obvious” solution.

Each of these properties contribute to comprehension of the solution out of its context.

Definition of a “hack”

A clever or elegant technical accomplishment, especially one with a playful or prankish bent. A clever routine in a computer program, especially one which uses tools for purposes other than those for which they were intended, might be considered a hack. – The urban dictionary

In short, applying objects and tools in a different way than originally intended, to solve a problem they weren’t originally supposed to solve.

Why simplicity matters

Now, let’s go back to the 3 properties previously discussed as being critical to simplicity. Each of these properties contributes to the ability to recognize and apply the tools in the hack.

Specialized easy matching due to most exact, i.e. least restrictive, requirements/input parameters.
Unoptimized no under-the-hood surprises when applying a solution differently. If there are strong ties to the original problem/solution domain, then it will be difficult to apply it to a difficult problem/solution domain.
Reduced most succinct expression of the solution allows for easier matching to alternative problem cases. Therefore easily recognizable as a candidate for solving another problem.

The simple solutions are easier to match than the complicated ones, exactly because they are simple in nature.

There is a certain skill in applying a good hack. One needs to be able to comprehend not the superficial combination of problem & solution, but rather the details as to judge whether or not it can be applied to a different problem/solution domain. One needs to be able to see through the original intentions and map existing solutions onto a new problem (domain). The difficulty of recognizing possibilities increases as more of the context changes. For example, same problem domain but different solution needed. Or, different problem domain and different solution domain. Therefore, one can only match on characteristics/abstract pattern.

Hacks composed of multiple parts

Now, apart from the “all-in-one” hacks as described above, where one considers a single solution for use at a different problem. In more complicated cases, one needs to consider parts of a composite solution, because a single ready-built solution does not exist.

The same principles apply: for each of the parts, identify what you can use. See what is missing and find a solution for that. The principle really is not difficult at all. It has the feel of a good puzzle. What is difficult is discovering the right bits and pieces by thoroughly understanding the original solution characteristics and recognizing suitable parts. Your thorough comprehension of available pieces determines your success in composing a good hack.

Are hacks better than solutions?

So is a “hack” better than a dedicated solution? … Well, maybe. The “dedicated solution” does not have to be perfect. So, a good hack may be better than a bad dedicated solution to a given problem. However, hacks typically satisfy the “sufficient condition”, meaning they provide something that is sufficient to solve the problem. However, nothing is said about what other things, complexities, dependencies, etc. are included as unintended consequences. Therefore, the hack may only be convenient for a short while, a temporary solution to an urgent problem.

Changelog

2020-04-02 Changed ‘prescribed solution’ into ‘dedicated solution’ as a more accurate description of the kind of solution that is intended. Misc rewording for clarity.
2020-03-31 Initial version.