Blame Tooling, Not People

Any time you ask your team members to “remember to do X”, at some point they’ll forget. Or they just didn’t understand you in the first place. Or they were out of office the day you brought it up. Or you’ll have new team members join who never heard your advice. You can almost guarantee that at some point somebody won’t do X. Here’s a few examples of X:

• “Remember to run linting locally before you commit”
• “Remember to run the tests before you merge”
• “Remember to update the changelog”
• “Remember to write tests”
• “Remember to think about accessibility while you’re coding”
• “Remember to rebase before you merge your PR”
• “Remember to squash merge your PRs”
• “Remember to update the lock file before you commit”
• “Remember to read these docs before you make changes in this section of the code”
• “Remember not to increase the bundle size”

When somebody doesn’t do one of these things, it’s much more effective to blame (and improve) the tooling rather than the individual.

Tooling is much more effective than people at preventing mistakes, encouraging patterns, and discouraging anti-patterns. All of the items in the above list could all be caught by tooling.

Let me take a step back and explain what I mean by “tooling”. Tooling can include any of the following:

• Testing tools (e.g. jest, cypress, lighthouse)
• Linting tools (e.g. eslint, prettier)
• Static analysis tools (e.g. typescript)
• Bots that leave comments on PRs (e.g. danger.js)
• Bots that send messages to slack (e.g. Slack Notify)
• Pipelines (circleci, travis ci, jenkins)
• Source control (github, pre-commit hooks)

So let’s re-visit the items at the top of this post and try to apply tooling to them:

• “Remember to run linting locally before you commit”

  • This is not necessary if you run linting with auto-fixing in a pre-commit hook

• “Remember to run the tests before you merge”

  • This is not necessary if you run tests as part of the pipeline

• “Remember to update the changelog”

  • A bot can leave a comment on the PR if the changelog is not updated

• “Remember to write tests”

  • A bot can leave a comment on the PR if it doesn’t see any test files

• “Remember to think about accessibility while you’re coding”

  • Some issues can be caught by running a lighthouse audit as part of the pipeline

• “Remember to rebase before you merge your PR”

  • Github has a setting to enforce rebasing before merges

• “Remember to squash merge your PRs”

  • Github has a setting to enforce squash merges

• “Remember to update the lock file before you commit”

  • A bot can leave a comment on a PR if dependencies are added and the lock file is not updated

• “Remember to read these docs before you make changes in this section of the code”

  • A bot can leave a comment on the PR with the link to the documentation if it sees changes to a section of the code

• “Remember not to increase the bundle size”

  • The bundle size can be measured as part of your CI pipeline and reported on a PR by a bot

With a little creativity, tooling can catch many problems. I believe tooling to be so important, that I’d wager the performance of any technology based organization is highly correlated with the quality of the tooling.

In short, blame the tooling, not the people.

Written By Ben Lorantfy

Ben is an award-winning software developer specializing in frontend development. He builds delightful user experiences that are fast, accessible, responsive, and maintainable and helps others to do the same. He lives with his partner and dog in Kitchener, Ontario.More About Ben »Follow @benlorantfy on twitter »