Test Driven Development (TDD) is gaining more acceptance in programming circles. But at least one question still remains. When should you apply TDD? In other words, when do you develop the tests? A simple answer is to create the tests first. That way you have tested code from day one. However this may not always be the right way to go.
I read a blog entry stressing that TDD is beneficial for maintenance work. You should have mature code complete with self tests. However the very first class you write for a new system may not need tests right away. Testing may in fact get in the way of rapid progress. I myself am divided on this very topic.
In a perfect world, you would have understood all the requirements and performed a full analysis and design on the project. At that point you are ready to add TDD before you write the first line of code. The real world is never perfect. So this may not be the way to go. Sometimes you need to write some code to figure things out. I would not call this production code. This may be throw away code. And that code does not need TDD applied to it.
We do not use TDD in general on my project. I have tried it. For small tasks it seems to work well. But when everything is crazy and we are terribly behind schedule, the TDD goes out the window and we hack together solutions. Sure it is not the best way to go. But it is life. There is probably a time and place for TDD. That time may not be before you write any code.
Mysterious Double Instance Hampering Performance - I study the existing code base. Confer with a colleague. Then I determine the optimal plan to change the functionality to load only a slice of all the dat...