I'm sure I'm not the only one who got down the road to overscoped features by saying "gee, wouldn't it be cool if my users could access this info that's living in a mysql table" and threw something together with a little php mysql_query(SELECT...), and it worked! except for some edge cases with non-ascii characters and the fact that you knew you were opening yourself up to SQL injection attacks, but you weren't really concerned because you only have 100 users and they're already authenticated by a more robust system. Anyway, you decide to do it the "right way" and rewrite it using SQLAlchemy. In the mean time, your coworkers wonder why you've burned half a day rewriting a feature that worked just fine after you had only been spending 30 minutes on it.

Sorry, that was a long way of pointing out that us novice programmers often don't have good methods of determining how long something should take because we've never done it before.

Another part of it is simply being good at automated testing. For me this was the biggest point of TDD—to force myself to learn to test anything and everything. At the end of the day all code must be tested, it's just a question of whether you are doing it manually or not. For one-off scripts and such manual testing is the sensible way to go, but for long-lived codes tests are an investment. Of course the value and necessity of tests varies quite a bit by language as well.

I agree with your point that it might be worth paring back features to improve code quality.

But there is no one true code to test ratio. If you're trying to become a better programmer be wary of dogma.

As posted here the other day, airbnb didn't have much testing until a year ago: http://nerds.airbnb.com/testing-at-airbnb/

I'm not saying either way is right or wrong, which is kind of my point.