[simonw]

"For the longest time, I would NOT allow people to write tests because I thought that culturally, we need to have a culture of shipping fast"

Tests are how you ship fast.

If you have good tests in place you can ship a new feature without fear that it will break some other feature that you haven't manually tested yet.

[ephou7]

Exactly. OP seems to have very limited understanding of software development if that fact has eluded him.

[Hamuko]

I think the more specific description would be that "not writing tests allows shipping fast today, writing tests allows shipping fast tomorrow and afterwards".

It wasn't too long ago that I wrote tests for something that was shipped years ago without any automated tests. Figured it was easier doing that than hoping we won't break it.

[simonw]

Yeah, but in my experience it really is a literal today vs tomorrow thing.

Your tests pay for themselves the moment you want to ship a second feature without fear of breaking the first.

[Ekaros]

If you are going to test what you develop might as well write any tests you do formally right away. It is unlikely you get it fully ready in one go, so you need to anyway run same tests again when you iterate it developing it today.

And that is the minimum level to aim at. If you can automate anything you do to test it right now you should.

[iddan]

Worked with a CTO that had the same rule of thumb. I quickly proved strategic testing is net positive for the business

[pastescreenshot]

The rewrite version of this that has gone best for me is to do it as a strangler, not a reset. Pick one ugly workflow, lock in current behavior with characterization tests, rebuild that slice behind a flag, repeat. You still get to fix the architecture, but you do not throw away years of weird production knowledge.