Not writing unit tests can drive more value than writing them if one
makes a good gamble. More often than not TDD pundits argue that if you
don't have tests you can't easily and rapidly discern a buggy system
from a solid one. They claim you can't effectively explore your code
base by utilizing the tests for hypothesis testing. They claim that
it's risky and wasteful.
a solid risk mitigation technique, that if followed to the T can
ensure your code will only increase in quality and robustness. Most
self-respecting developers accept that. The controversy which
surrounds this subject usually revolves around whether or not the time
invested can be rationalized as driving a sufficient amount of value
to make it worthwhile. Most controversial is the idea that everything
you program must have a test rather than just most of what you
program. Not having a test to cover a change to the program means
there's more of a risk that a bug could creep in. How do we leverage that risk though? The case can be made that unit
testing code can take longer than just programming what you want.
Those of us who feel very strongly about TDD would say that might
happen but you'd have to be lucky to get code without many bugs.
Others would argue against that but I say ok sure! Let us assume that
you'll only get that code done correctly, faster if you're lucky
but... How lucky? How much do you stand to gain if you win? Do you see
where I'm going here? Risk can drive an exponential increase in a return on your investment.
That's an economic fact. If you accept that as well as the idea that
not unit testing is risky (as opposed to impossible) then you
hopefully agree with me on this. I don't care what your stance is on this subject, this is a rational
argument for strategically not testing aspects of your code. Now if we wish to argue this subject in the future we need to argue
the specific contextual situation of each developer. For some it is a
potentially profitable venture and for others it would be enormously
expensive. Now we can frame the whole debate as being so hard to
definitively settle due to the unique data that we'd need to
rationalize it at every company. This is nothing new as many of us
who've been arguing for unit testing have given up arguing with some
people. Both sides huffing while the TDD person says you really just
need to try it for yourself. What they're really saying is you'll need
to run your own study at your own company to see if the practice is
right for you. Some of you will say that's fine but the developers who do this will
be accruing a hellish technical debt over time that they'll eventually
have to pay off. Technical debt is really the wrong model for what we're discussing.
Why do we have to pay it back? I'll wait for the laughing to stop but
once you've caught your breath please really think about this. If not
"improving" that code is driving a hefty increase in value then we
don't really have to because what we're actually doing is leveraging
risk. That's actually why the whole debt analogy really works in the
first place, because debts are assumed risk, the difference being that
the investor needs to be paid back. Instead, if we view them as
gambles, we understand that it's possible to get Black Jack, or a
royal flush, or hit the jackpot. Remember every decision we make every day is a multivariate
optimization problem. "Experts" give us their recommendations based on
their own personal experience, but every company is different. If you
don't have the data you need to support the cases you wish to make
start collecting it now.