Thread by @RonJeffries

So you're a programmer, and there's this thing where you produce some code, and some time later you, a colleague, a tester, or a user finds a problem with it. Maybe they give you an example. It's rarely a very good example.

1/5

When you go to deal with the problem, you refresh your mind on the code -- after all, you've been doing other things -- and you try to isolate the defect.

Usually if you have an example you have to refine it, either as a simpler test or just by stepping and probing.

2/5

The code-test-fix delay slows the delivery of good code. The interruption slows down what you were planning to work on. The relearning of the code is limited and you often don't work with it as smoothly as when you wrote it.
The example, if you got one at all, was flaky.

3/5

The problems you're handed tend to be larger, with multiple causes.,
Almost everything you learned debugging and stepping goes by the wayside: it has no good way to take up permanent residence in your mind or in the code.

4/5

All this bad stuff is caused by coding, then testing, then fixing.

We can turn this around.

We call our shot: produce the example first, ideally a tiny one.
We program until the example works.
We repeat.

We call this TDD.

5/5