Why test driven development works
Yesterday, when I was waiting for my program to start on android I start thinking that I lose quite some time for this start-click-see result cycle. If it takes 30-50 seconds to build upload and start new apk on android, then it can easily end up as half an hour a day just restarting the app.
Then I started to think why I am starting the app so frequently and the reason was simple.
I want to see results of my work.
I want to see how the lines of code I type in eclipse actually doing something, how click on a button works, etc. This is very important thing in any job — to be able to see results of your efforts. When time between this work – result feedback is shorter, and results are easier to understand, then it easier to be more productive.
Now, lets take a look in software development. If you are writing software which is more complicated than Celsius to Fahrenheit converter then you should expect the delay of being seeing results of your work larger. Time for self-feedback increases and you can find yourself writing some code not knowing when it will be actually used. This affect your motivation in bad way and productivity decreases.
When you use test-driven development approach you are creating goals for yourself. First you write test which fails and then make code to pass this test. This is good goal because
- It is identifiable
- You decide how big goal is
- You are getting feedback and ability to see results of your work.
I think the last point is most important, it really takes a lot of effort to keep hight productivity while not being able to see “immediate” results of your work. Having a goal of “releasing product” or building “perfect solution” is great and crucial for actually finishing software, but for everyday work you and members of your team need to see results of their work to see that they are progressing.
Thats why you should consider test-driven development. Thats why it works.