No. Cutting your deployment time is equivalent to saving a one-off cost. A comprehensive set of automatic tests is a massive ongoing cost (it's by no means impossible for the tests to cost more than the product), forever. The latter vastly outweighs the former.
There are domains in which you need the tests anyway. If you're in one, you'll probably find your deployment cycle is also constrained by the nature of the domain. If it's not, and if the existence of the tests lets you deploy faster than you otherwise could have, well and good. But it certainly isn't worth investing in the tests just for faster deployment.
> Cutting your deployment time is equivalent to saving a one-off cost.
No, cutting deployment times produces ongoing savings in two respects:
1) Time is saved on deployment every release. That may be a small amount relative to the engineering that goes in ahead of releases, but it's definitely not a constant: it's proportional to the number of releases. When one considers not just major-version-every-six-month releases, but also maintenance releases, hotfixes, patches, etc., the time savings is increased even more.
2) As Joel discussed in the post, there are lost opportunity costs when a team develops a feature and does not immediately release it. Presumably, those features are intended to directly or indirectly increase sales/revenue: the sooner they are released, the sooner they can begin making the company money. This money is proportional to the number of features/improvements.
Investing the engineering effort required to achieve a shorter release cycle doesn't always make sense, but it definitely always produces value proportional to elapsed time.
> Cutting your deployment time is equivalent to saving a one-off cost.
I don't see how that's true! Could you explain it?
My experience is that short release cycles mean better feedback loops, which means quicker bug fixes and less flail about deciding what features to spend time on - so you get an ongoing improvement in speed.
There are domains in which you need the tests anyway. If you're in one, you'll probably find your deployment cycle is also constrained by the nature of the domain. If it's not, and if the existence of the tests lets you deploy faster than you otherwise could have, well and good. But it certainly isn't worth investing in the tests just for faster deployment.