Catching mistakes earlier

Last week, I wrote some boring code to add a dropdown to a dialog. Everything looked great on my end, another engineer gave it the ol’ 👍 in code review, and I submitted the code before rewarding myself with a celebratory orange mocha frappuccino.

Three days later, our designer sent me a Slack message: “Your dialog is missing a heading. Mind fixing that?”

This is a (true and totally representative) example of one of the sneakiest problems I see slow teams down. A mistake that should have taken me one minute to fix at the source will now probably take 30 minutes to fix by the time that I stash my current work, create a clean workspace, remember and reopen the relevant files, make the changes, send them out for code review, get approval, wait for tests to finish, and submit the changes. Worse yet, the same pattern plays out on a larger stage with weeks of wasted effort on solving the wrong problems entirely.

Toyota gained a pristine reputation for value and reliability in the 1980s by fixing this exact problem on the automotive assembly line. A key tenet of their manufacturing process is that mistakes are significantly faster to fix when you catch them early. Want to make it take two hours to tighten a bolt? Slap an engine and a hood on top of it. Want to churn out high-quality cars quickly? Figure out how to catch your mistake closer to its source.

For software, here are some relevant questions to chew on:

While coding (stop mistakes from reaching code review):

• Do engineers and product designers regularly meet before implementation to make sure the scope is clear?
• Do you have precommit hooks installed to help engineers remember any “quick but easy to forget” things to do before pushing their branch (e.g. formatting, linting, schema file generation)?
• Are coding conventions enforced through linter rules instead of code review?
• Do engineers regularly ask designers to their desk for quick, informal checks when they’re unsure about a particular design choice? (Sharing a local instance via ngrok is a good-but-not-perfect replacement for this.)

While reviewing code (stop mistakes from reaching QA):

• Do you have comprehensive integration tests that cover most of your app’s behaviors?
• Are your integration tests reliable?
• Do your integration tests need to pass in order for a branch to be merged?
• Are designers able to participate in the review process via review environments?
• Are common “don’t-forget-tos” enforced via integration tests (e.g. updating schema files, formatting code)?

While prioritizing features (stop mistakes from reaching coding):

• Has this feature been explicitly prioritized above other, still-unimplemented features?
• Is there a clear system to convey prioritization to engineers?
• Did engineers get to participate in scoping the issue?

By catching mistakes earlier, you can restore your focus to where it belongs: getting that perfect sip of Frappuccino.