Re:Why slow thinking wins
by falcolas on Monday July 27, 2015 @09:12AM
(#9954930)
Perhaps I'm just begging to be flamed, but I've noticed this quite a bit with TDD. It's easy to write a test case, jiggle around the code until it works, and then call it "ready".
In an ideal world, the jiggling around would be followed by a review of the relevant codebase and a good refactoring, but this step is pretty universally missed in my experience. Additionally, the thinking should be occurring in the "build the tests" phase, but it's not. Or rather, only the "happy path" tests are built; the corner cases and error cases are missed or outright skipped.
I noticed this in myself first, and slowing down has definitely helped. As has spelling out the test cases before touching any code.
In an ideal world, the jiggling around would be followed by a review of the relevant codebase and a good refactoring, but this step is pretty universally missed in my experience. Additionally, the thinking should be occurring in the "build the tests" phase, but it's not. Or rather, only the "happy path" tests are built; the corner cases and error cases are missed or outright skipped.
I noticed this in myself first, and slowing down has definitely helped. As has spelling out the test cases before touching any code.