Tool Complexity

Recently, I had a conversation with a few colleagues about the complexity of software tooling. It came up after a humorous post that complained about a particular tool (I won’t say which) being overly complex. Not just complex, but the author claimed it was maliciously and intentionally designed to be complex as a form of gatekeeping.

It seemed as though this person ran into the same pitfall as a lot of developers: being expected to quickly learn an unexpectedly complex tool.

On the one hand, this particular case felt silly and over-the-top because it appeared they didn’t take the time to learn the tool. On the other hand, it is a very unintuitive tool.

Without giving away too much, the main point is that the tool doesn’t just solve a single problem; it solves numerous categories of problems and does so relatively elegantly. Unfortunately, using it for the simplest cases still inherits the necessary complexity for the more advanced use cases.

Beyond that, this tool is taught as though it is “easy to learn, difficult to master”. In reality, the difficulty curve is shaped like a reverse “L”. Because many are not warned of that difficulty upfront (or they choose to ignore it), they don’t see the difficulty cliff until after they’ve been burned.

Even if this tool were taught better (and I’m personally trying to improve just that), this tool is not exceptional in its unintuitiveness. Dealing with complexity is part of the nature of software development.

I want to claim that, while it has immense value, intuitiveness (or lack thereof) is not the only design goal or decision for… anything. Some tools are needlessly complex, while others are needfully so. For a given tool, which is the case is both relative and subjective, and highly dependent on your use-cases (“right tool for the job”).

Alternatively, it would be gatekeeping or elitist to say “I like this tool’s complexity because it weeds out Bad Developers”. That statement is inherently biased to believe that only one type of developer should exist; all others should disappear. Extending that to assume all complex tools are inherently elitist or malicious is fallacious.

When it comes down to it, learning and understanding complex tools, languages, and interfaces is not gatekeeping, it is part of the job description.

To sum up:

• Yes, tools should be made more intuitive where reasonable.
• Yes, some tools are needlessly unintuitive.
• Yes, there is a lot of gatekeeping and elitism in software development.
• No, these are not all the same thing.