Test before you Guess

Test First, Test Driven Development, TDD, et. al. that represent this now not so new, agile way of developing software... we haven’t jumped into it yet. There is a hurdle and much has been said about this barrier. It can be a hard sell if your audience isn't ready to hear it.

Really, how do you make the case to the people writing the paychecks and putting their necks on the project profitability line that this isn’t some techie geek indulgence? Well:

• Look, it’s a lot of effort up front, and we would rather be writing code and smoking with the time saved not doing it (up front, that is), rather than devising, cataloging, and coding these tests and associated harnesses and refactoring classes into testable units.


• When you suits want to get a handle on the state of the project, or its quality (i.e., do we have a handle on WHEN it’s going to be FINISHED and ACCEPTED), we can almost tell you.


• When (not IF) a change request is accepted and implemented, re-running the tests will tell us if it's broken the rest of the system, without guessing or losing sleep.

The rejection of the myth that we go from requirements-> design-> implementation-> testing-> delivery, in exactly that sequence, is the difference between being effective and failing. TDD sets up your processes to cope with this. Yes, after two weeks using TDD, you may appear way behind, but once the software is feature complete, you won’t be called to the carpet as much for blowing estimates, requirements, QA time, and client agita. That's time well spent, and saved.