Stress and TDD

In Blink the author describes that there is an optimum peak of performance in regards to stress. What happens after that peak is reduced performance, inability to act on details and tunnel-vision so on.

In programming this means we will see the end goal, often the finished functionality according to a specific happy path scenario (that is developer specific). This means we will skip extra checking, and testing. We are not considering the alternative flows of the application. The end result when too much pressure is applied to software development is that things loose quality as the developers sight narrows.

TDD from a process perspective is designed to help developers maintain quality as the temperature rises. If the developer safely can write test for what he is doing, then there is an extra automatic quality gate for the production code to pass. Each test is a statement of the assumptions made by the developer as he or she writes the production code.

As a programmer I make decisions and assumptions all the time. I can see how stress cause a lot of the bugs that I’ve seen. In essence I think that this is what TDD is meant to resolve, to give you a framework that even though your stressed beyond cognitive functioning your decisions are recorded, and if you do something that breaks a previous decision, especially during a stressful period, you will be informed accordingly and forced to think.

However if you push hard enough something will break. What can break down instead? The obvious answer is Discipline.

Removal of tests, badly written tests, simply not writing tests etc. All you do is push the problem into the test suite. With a badly written test suite your production code will suffer.

So the question is: Can you correct an organizational problem with a methodology?