In TechEd 2008 David Platt interviewed Roy about the future of TDD. You should really view the Tech-Talk as Dave is really funny, although he does miss the number of possible TLA’s (which he recursively defines as a TLA = Three Letter Acronym) by 300.
About 5 minutes into the session David asks a key question: “What happens if your boss comes and says: I’m in a hurry, I need this, come on we need to ship this, we need to hurry up, forget about the tests“. What do you do?
I think that David has a valid point that is extremely important to address, as many teams are under pressure and they willing to find any excuses to ‘just code’. This question is going to define where we are going as a profession.
So what keeps us professional, what keeps us from doing cowboy development as Dave suggested that has been proven to lead us to more costs?
As Roy Said, it is a well defined process that will save ourselves from this pitfall, and writing unit tests is one of them. Just like professional teams will not even think of ditching their QA process, developer teams can not afford, in these economic times, to ditch unit testing. As a matter of fact, once you start unit testing you will find that you will be under less pressure!
You will spend some time writing tests (which you would have spent anyway on manually testing the application), but the ease at which you can continue to add functionality without breaking the code, will return that investment in no time. So the quickest way to implement a feature is actually using unit tests! I have seen so many teams make the mistake of not writing the tests, and within a few hours, they are already introducing bugs and are afraid to add features as they might (and probably will) break the code.
So back to Dave’s question, what happens if your boss is in a hurry? Be professional, just write the code and the tests as fast as you can. This is the most efficient way to write software.
I think this is an excellent point/post. Often the cowboy coder feels he doesn’t need tests anyway because he ‘knows what to do’ and ‘knows what the current code does’; so he uses this ‘pressure’ from management(or whomever) as an excuse to ‘get ‘er done’.
I can’t count how many times I have sat and watched the unreformed cowboys I work with do build after build after build after build on a revolving door of bugs all related to some project that was ‘high priority’ and therefore the cowboy coder just went out and did it, totally abandoning the process. On many of these occasion once the dust settled the time spent on the revolving door of bugs was greater than the original coding time, and far greater than if the code would of been done right, following the process. But then, that shouldn’t come to a surprise to anyone who truly understands the value in testing.
But note: there are two problems here: the cowboy coder, and the catalyst – the manager who encouraged this kind of behavior. Both need to be dealt with, not just the coder.
True Anon
There is only one solution: The manager.
It is the managers job to create professional software and to do so the manager must make sure that the cowboys become professional too.
Even if it seems counter-productive to writing unit tests instead of another feature – this is what professionalism means.