This summarizes my experience to a tee. Early on I've found that little compromises on internal quality come back and bite you almost right away. Compromising o

This summarizes my experience to a tee. Early on I've found that little compromises on internal quality come back and bite you almost right away. Compromising on that only makes sense if you're 'building one to throw away', in which case rapidity of learning is probably the priority. The problem is that the decision makers almost never want to actually throw it away when the time comes. I've been doing TDD a long time (18+ years), and I'm definitely pragmatic in the sense that I don't test everything, definitely don't aim for 100% coverage, and don't use mocks often, etc. I aim to extract most of the value from the tests without paying an absurdly high tax on them. Still learning in that regard, but I have had some real successes in testing. I find this is key in our broader team's ability to keep the internal quality high. It's obviously easy to mess up a code base, but (high quality!) tests have been an important part of that, in addition to refactoring, code review, etc.