I used to think I was good at programming. Since I started doing TDD in 1999, I’ve come to discover that I am not so good. I make a lot of little mistakes. Copy-paste is a specifically error-prone activity for me. When I copy and paste and N changes are needed, on a good day I can usually get N-1 on the first try.
When I’m almost done, I get a little careless. I’m not the only one! Take a look at this analysis of the Last Line Effect. He show lots of copy-paste bug examples from real code from products you know. In the article the author also mentions this may not be just programming.
mountain-climbers often fall off in the last few dozen meters of their ascent. Not because they are tired; they are simply too joyful about almost reaching the top – they anticipate the sweet taste of victory, get less attentive, and make some fatal mistake. I guess something similar happens to programmers.
I’ve watched a lot of programmers program in training context. They are not so good at programming either. Little mistakes are the norm, not the exception. But programmers generally don’t know how error prone their work is, because the feedback loop is too long pre-TDD. TDD puts the mistakes in your face so you can find them before they hatch into bugs.
With the mistakes in your face, you can certainly see them and fix them. You might, though awareness, start to do them less as you work on your weakness.
Hi James. Your book and work have inspired mine and I have developed methods to apply TDD to all stages of development of any problem.
Recently I combined control theory with TDD methods and have created a mathematical proof for TDD and can demonstrate why it is superior to traditional methods.
Please help me to demonstrate the ideas.
P.S. You need to do something about the time limit on that Capcha. Fourth time of trying now.