I was talking to someone who had had a project manager mention in a retrospective that he felt that the testing was slowing down the delivery. They wanted to stop “wasting time” on testing and refactoring.
When I heard this, I said “That’s a bit like going on a car journey and your passenger telling you to ignore the oil pressure light because they don’t want you wasting time topping up the engine oil”
Admittedly, you will get underway faster, but that’s going to be very little comfort when you come to a grinding halt a few miles down the road.
Maybe even more notable, at sxsw I went to a panel on scaling webapps and was given this exact line of reasoning by some obviously competent dev leads from successful internet companies. “We’re a startup. We’re resource-constrained. We don’t have time to write tests”.
I don’t want to ridicule these people – you have your set of experiences and you can’t have absorbed everything the development world has to offer.
But we know that we write tests precisely because we’re time-constrained. I think this should get more emphasis than it does: a well-crafted, fast-running unit test suite is an incredibly powerful productivity tool. If your time horizons are > 1 month, your team will spend a punishing amount of time reorienting the codebase to accommodate changes and new features if correctness must be proven at human-using-a-browser speed. For a modern startup it could very well mean death.
Perfect analogy!
I just gave a talk last night on the business value of TDD and particularly refactoring, and I find that–in order to get real buy-in–I’ve had to finish this particular talk with three actual first-person stories about how the team I was on turned a sudden, surprising, and “architecturally challenging” story into over $100,000/year savings or revenue in a matter of days. I know for a fact that all three of those would have ended in disappointment if we hadn’t been completely covered with fast, automated regression tests, or hadn’t been refactoring with a very low tolerance for subtle code-smells. (That was one point of the talk I aimed at developers: On a TDD team, you’re not refactoring messy code, you’re cleaning CLEAN code. Like a sushi kitchen, you never leave it even a little messy.)