Claude Montpetit -- Montpetit.net -- en

A study shows that people at a racetrack are much more confident that they picked the right horse just after purchasing the ticket than they were 30 seconds before (Knox and Inkster in 1968, Rosenfeld, Kennedy, and Giacalone in 1986, both with similar results.)

In a wider scope, this attitude is labeled as Commitment and Consistency:

Once we have made a choice or taken a stand, we will encounter personal and interpersonal pressures to behave consistently with that commitment.

This human pattern is often used as a sales strategy:

The key to using the principles of Commitment and Consistency to manipulate people is held within the initial commitment. That is--after making a commitment, taking a stand or position, people are more willing to agree to requests that are consistent with their prior commitment. Many compliance professionals will try to induce others to take an initial position that is consistent with a behavior they will later request.

Commitment and consistency helps manage the incredible amount of information that reaches us: we can accept certain things and forget about the reasons why we agreed to them. Without this, it would be very hard and time-consuming to debate internally about every thing all the time. I have personally noticed that it is often painful to deal with something that has not yet been classified in my internal catalog of values, especially when the subject matters to me. The indecision period is not comfortable and requires the effort to think about it. Once the decision is made, I feel better and I can move on to something else.

I think there is a lot of Commitment and Consistency in the world of programming. While writing code, or debugging a problem, we are living in a creative stage. Once we believe we have found the bug, or completed the code, we approach commitment. But the code has not been tested (tested does not mean compiled and run a few times, it means tested.) This is a critical moment. The temptation to commit is big. The code is written, the creation process is over. Committing at this stage is simply a matter of switching our minds and suddenly believe that our code works just fine.

In the creative stage, we feel good. Approaching commitment, we feel uncertain. After commitment, the insecurity simply goes away and we can move on.

Reading about these human patterns reinforces my belief in the benefits of testing WHILE developing. Testing during code production is a necessity because once we have completed the writing/compiling/running stage, it becomes very hard to stop production to write tests before or after commitment.

• If we resist commitment when writing tests, we can feel that tests are speed bumps, and that they reveal and maintain our uncertainty about the quality of our code. Anyhow, this is not a comfortable situation.
• On the other hand, if we do not resist and perform a mental commitment before writing tests, the consistency rule kicks in and we are in trouble. This rule will prevent us from writing good tests: How could I intentionally break the code that I mentally accepted as valid? That would be inconsistent.

The best option is therefore to write code and tests at the same time. Nothing new here.