Test Driven Development

Read this book from Kent Beck recently, called Test Driven Development (TDD). There has been a lot of interest in the so called Unit Testing, where the developer are responsible for creating the test for the "unit" they are implementing. What a unit is is arguable but the general rule seems to be per class object for OOP development. TDD is an approach for developers to implement such unit test based on a "test first" philosophy. Create the test, get the test to work, then refactor to generalize the software and the test itself. Thus the programmer will be interleaving between development of the software and the test.
Kent's TDD approach is red bar, green bar, refactor. Red bar is when the test is not passing through thus the programmer should do whatever (dirty fix) to get the test to pass - that is getting to the green bar. Once the test is working then you have to refactor your code to work for the generalize cases (removing "duplication" is his term). I was amazed that this approach resembles my own natural approach to programming. The difference is that Kent is formalizing it into a discipline (habit) while I do this informally and without reusable test cases. Thus my testing effort during my programming was wasted. The hardest thing abut TDD is that you have to spend a lot of time thinking about the testes and also the need to refactor it as the program is refactored. I still have not tried the TDD but I have plans to try it out to see for myself how whether the effort to create the test is high and whether it is worth the effort.
Another of Kent's arguement is that TDD can help drive the design of your software (Object classes in particular) -- this is because you are getting your hands dirty and playing around with the object -- trial and error like style. Sometimes that is very true as there are times when you just cannot think of a good way to start thus the best way is just to start whatever - even if it is a bad design. This helps you to start thinking and find out the details of the problem. If the result happens to be bad then throw the code away - at least now you know what is better!
Software engineer is a discipline so it makes sense to discipline your habit of development - only if it suits your approach to programming. Everyone is different so do what you will but just make sure it improves the quality of your software.