When NOT to use a tool/paradigm/workflow

Using the right tool/paradigm/solution/library/workflow for a job is widely regarded as a good idea.

It's the opposite of cargo-culting, which means blindly using a tool because others do, without necessarily knowing their reasons.

< / obvious >
< point >

Everyone who is selling tools will usually praise theirs as silver bullet for a wide range of use-cases.

What is missing is the information, when not to use it, or cases where that tool is not a good choice.

Lately I have come to appreciate tool-authors, vendors, experts and teachers who clearly state that…

…our book may not be for you.
…you should use a simpler approach.
…this library introduces too much overhead for your project-size.

It's an act which might prevent some purchases or downloads, but…

…it immediately builds trust.
…it provides usable information.
…it can prevent frustration in the long run.

Positive examples I came across more or less recently:

• "You Might Not Need Redux" by the author of Redux

• "When and Why to Use Docker"

I'm curious about more examples of "do not use our product if…"!

Comments

[Olivier Jacques]

Thanks for this article. I agree that this is a good posture to have when you position your work / framework / methodology. It actually helps with adoption if you know what to NOT expect.
I feel the attitude is very close to “learning from failure” when I share what did not work for me or when s...t happened.