It’s useful to compare the effort spent writing tests up front to time spent debugging. Debugging often involves looking through large amounts of code. Test-First work lets you concentrate on a bite-size chunk, in which fewer things can go wrong. It’s difficult for managers to predict how long debugging will actually take. And in one sense, so much debugging effort is wasted. Debugging involves time investment, scaffolding and infrastructure (break points, temporary variable watching, print statements) that are all essentially disposable. Once you find and fix the bug, all of that analysis is essentially lost. And if not lost entirely to you, it is certainly lost to other programmers who maintain or extend that code. With Test-First work, the tests are there for everybody to use, forever. If a bug reappears somehow, the same test that caught it once can catch it again. If a bug pops up because there is no matching test, you can write a test that captures it from then on. In this way, many Test-First practitioners claim that it is the epitome of working smarter instead of harder.