Skipping Tests To Deliver Faster

Managers with looming deadlines often tell developers to skip writing tests in order to deliver code faster.  This only makes sense if you don’t believe that unit tests pay off in initial development, or you view the impact of bugs as an externality.

I have encountered extremists who don’t believe that unit tests ever provide value; that’s not the case here.  Managers who want to skip writing tests to deliver faster are less extreme.  They are stating that unit tests pay for themselves over time and that they won’t provide a net benefit until after the first release.

This is not as crazy as it sounds.  Tests become more valuable over time as they allow future developers to refactor with confidence.  You can reason backwards and say that if the test is more valuable in the future, it must be less valuable today.  Right now, the test could even conceivably be worth less the cost of writing it.  And when you need to ship, you cut things that don’t add value.

Which brings forth the second part of the argument: bugs are an externality.

If you deliver a bug ridden project on time, have you succeeded?  Sadly, the answer is usually yes.  Managers get evaluated on delivering on time, developers get evaluated on quality. Managers can believe that tests add value to the code, but they don’t add value to the manager.

By their definition deadlines prioritize short term thinking.  Deadlines encourage managers to make short term tradeoffs at the expense of long term value creation.  When managers push to skip tests, the people who suffer most are customers who have to use the software.  The people who suffer least are the managers who traded tests for time.