Make it more effort to do the wrong thing

One thing I have observed in multiple software engineering and data science projects is inconvenient steps get skipped. This is negative and happens despite rules, best intentions and effort. Recently I have noticed a positive re-formulation of this in that project quality increases rapidly when you make it take more effort to do the wrong thing.

In many projects I noticed that unit tests, baseline studies and formal issue tracking all have a tendency to just stop happening over time. At best they occur in a secret side-channel where they can avoid formal tool and project overhead.

In the past I have used this somewhat negative assessment to criticize bad tools and procedures. Make it take 10 clicks to submit a bug report and all bugs will move back from the issue tracker to email. Make tasks harder and they don’t just slow down, they disappear.

However, more and more I am seeing a positive way to re-form this observation. If you add a little cost to doing the wrong thing then more and more often you instead do the right thing.

In data science projects I now less often require a written arguments that an estimator is unbiased (a very important property of statistical estimators). Instead I only ask that we characterize the degree of bias of all estimators. It turns out unbiased estimators in addition to being better are often much easier to characterize and document. A slightly more complicated estimator may be better and much easier to document.

In software engineering projects: don’t require detailed “as built” documentation (which both has a cost and hinders re-factoring). Instead insist on documentation of incorrect corner cases and all work around procedures.

A great way to encourage the elimination of tedious interactive GUI steps is not to insist on replication of results but instead to insist on detailed step by step documentation. The smart engineer will then automate everything down to one step to eliminate the need for documentation. And at that point you have the ability to replicate results for free.

Instead of requiring extensive “how to reproduce” documentation on known bugs, instead require detailed documentation and impact reports of known code inadequacies.

Don’t require extensive ROI projections for proposed innovations, instead requires detailed lost opportunity studies on your least liked legacy systems.

In all cases you want to attach costs to wrong steps not to the right ones.