
  Possible Duplicates:
  Frankly, do you prefer Cowboy coding?
  Prototyping vs. Clean Code at the early stages
  Good design: How much hackyness is acceptable?
  Does craftsmanship pay off?




Which is better:


Coding fast, not caring about possible errors and limits, maybe forgetting to check the input, NULL returns etc, just to complete the task or to get to the milestone, and then correct all possible errors.
Coding slow, checking every line you write many times, writing tests, and checking every possible input to make a code as bug free as you can but taking weeks to write a working program.


Actually I'm using the 2nd way but it's frustrating to work, work, work and see only small improvements every day...

This depends ENTIRELY on the type of work that you're doing. For a lot of situations Test-Driven-Development, like you're currently doing, is definitely the way to go. Overall you'll spend less time on the project since you're not having to constantly go back and fix bugs and edge cases that you didn't account for the first time around. With the first option, yes, you'll finish in record time but then you'll spend a good chunk of time going back and fixing all the mistakes.

That being said, if you're in a situation where you need to get a product out the door as fast as possible (maybe you're trying to beat the competition for "first to market" advantage), toss TDD out the window and get something working and out there. A lot of great products have happened this way. Your product won't get you anywhere if you're endlessly polishing and fixing bugs if a competitor with a "good enough" product is eating your lunch.

Consider Facebook. Mark Zuckerberg created Facebook in his dorm room with PHP and MySQL, at a time when probably twenty other people or organizations were planning or already releasing social networking sites. Part of the reason for Facebook's success was that he got out the door in a hurry and beat a good part of the competition solely because he was first to the college market.

If you have time: unit test.

If you are in a race: code, and get it working - worry about the mistakes later.

EDIT: Obviously, you can't release a product that is so buggy its unusable. When using the "out the door" method, you need to realize when hunting and fixing additional bugs will only add marginal value to your product when compared with releasing now.
