- Misconception #1. If we stop writing code test first, just for a little bit, we might be able to meet this
ridiculouslyshort deadline. – It’s natural to assume that cutting corners and not following your process for a short time will result in faster development. You can write code faster without writing tests first, but the result will be buggy, and hard to maintain. Add to that several developers writing buggy, poorly designed, and hard to maintain “cowboy” code and your going to start having development efficiency problems quick. Especially in the embedded domain where electronic signals can be hard to access.
- Misconception #2 If we fail to meet the deadline quoted above the sun will never rise and our customer will walk away. – I understand this impulse to please the customer at any cost. Sometimes in a sales setting this is the only mindset of the day. We have to be careful to manage the expectations of a customer in order to not end up in situations like this. In my experience this can be hard for managers to understand or even acknowledge. (There’s 24 hours in a day and 48 hours in Saturday and Sunday!) This is why it’s so important for TDD or any process to be implemented and defended from the top down. If a deadline looks unattainable it’s better to find ways to limit the scope of the deliverable or negotiate a more realistic deadline.
- Misconception #3 If we stop doing TDD for a little while we can always pick it back up again later. – What happens here is that your quality of code takes a nose dive. You have no guarantee that you will meet said deadline. And, once TDD begins again you will have a backlog of untested code that still needs to be tested and possibly rewritten. This is just setting yourself up for another unrealistic deadline
Cutting out TDD is no guarantee that you will meet your deadline. You could end up missing the first deadline, and the next, when, if you would have followed the process, you could have at least made the second. I think the right guideline for suspending TDD is to stick to hours not days. It’s alright to do a spike test and figure out how to get that widget to spit bits, but you have to write tests and re-factor in your next step.