Exactly. OP seems to have very limited understanding of software development if that fact has eluded him.
Re:
by pastescreenshot on Tuesday March 10, 2026 @04:05PM
(#47328138)
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.
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.
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.
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.
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.