[RobbieStats]

You are missing the point. At a small startup with limited resources you have to make tradeoffs. The tradeoff I've settled on is more functionality in place of 100% quality (if there is such a thing). I think people early on waste a lot of time trying to nail every single bug when some bugs just don't matter in the grand scheme.

Also, I'm not a junior programmer that needs someone looking over my shoulder to make sure I've implemented a spec correctly. Saying it doesn't do what I think it is doing is like saying that I may not exist even though I think I exist.

[btilly]

I have seen many senior programmers who think their code is doing X when it is really doing Y. I've seen a very small number of programmers whose code is always doing what they think it is doing. Every member of the latter group of programmers spends considerable energy double-checking themselves.

Therefore if you're taking short-cuts, the possibility that your code is doing something other than what you think it is is realistic, not ludicrous. Now it may be appropriate for you to take those shortcuts. But you shouldn't take them without being honest with yourself about the risk.

[RobbieStats]

But what do you consider a short-cut? How much testing is enough? Doesn't the situation dictate what is enough and what is really a short-cut? What needs to be tested at a startup IS NOT the same as what should be tested inside a large corporation.

And what "risk" are you referring to? As I've stated, I decided to side with "more features" than "100% test coverage". Sure there is "risk" that there are bugs, but a) there are bugs regardless of how much testing you do and b) I've decided I'd lose users because I don't have features that stand out above the competition rather than because a minority of those features have minor bugs. So to me, the bigger risk is not developing more features.