I don’t know what you mean by RFD here. Rural Free Delivery? Request for Documentation? None of the expansions I can find make sense.
Well the lesser issue is that we always learn things in development that we overlooked in design, absolutely always, even people like me who are adamant about design documents and have been employed as technical writers. But that’s just wasted-time wrong; OK, you’ll have to revisit the tests over and over, maybe some people call that job security, but I call it inefficient.
The far greater issue is that TDD says developers should be the primary, if not the solitary, testers of their own work. This is about as sensible as skydiving without a parachute. To believe this is crazy, junior, violently inexperienced; anyone who has ever done a project significantly larger than Hello World knows that we have blind spots in our development and these same blind spots will show up in writing tests. That’s why we have blackbox testers, people unprejudiced by knowledge of the code and who work from functional specifications.
I regard all this as elementary. It’s staggering that someone could work for more than a year or two and not feel this viscerally.
And then there is the crazy shit, the fanatic shit:
- we don’t need documents. The tests are the documents. This is mental institution level thinking
- unit tests are more important than code; better to cut corners in the code than in the tests. This is thousand-mile-stare fanaticism
- if it’s not TDD it’s not software development
That’s as much as I care to repeat what I’ve already written articles about:
Test-Driven Development is Fundamentally Wrong
It was late 2008 and I was writing an extension for the Windows 7 taskbar. My work was essentially finished, the final…
Here’s what I think is going on; concentration and focus are all but forbidden in software companies. Without concentration, and ideally the “in the zone” condition we call flow, people write inferior code. Interruptions lower code quality and productivity very significantly. And so like a lousy cook who rescues a tasteless cake with tons of sweet icing, people who write lousy code tell themselves that the solution is tons of tests. Because they’re never going to convince managers who believe in fads like agile and TDD that they’re wrong.
The solution is to bring back uninterrupted work. One meeting per week except for design sessions between people whose projects interact with each other, single-occupancy offices with DND signs on the doors, clarity in communication (try nailing down a meaning for “refactoring”), don’t interrupt people who are working.
Even a few years into development I could do weeks of work without writing a single test and have everything work but for a few trivial bugs easily found in manual testing and fixed in seconds. I’ve never written a unit test. I’ve worked with others who did and saw no value in it; a lot of work and almost never useful. I work well with testers and have had gigs where I spent a third of my time in my tester’s office.
The part I would most encourage you to think about is those blind spots. MANY times I tested my own work to my satisfaction and found nothing wrong, only to see a blackbox tester or even a coworker break it in under a minute.
Read my Flow article too. This is what made Microsoft great thirty years ago and their abandonment of it is why they’re the joke they are now.
I can understand how you might believe in TDD if you have never known a work environment that didn’t interrupt you all day, and you came to think this was normal. But when you advocate pair programming you create an unbridgeable chasm of understanding. I could understand if you were talking about mentoring or a code walk-through but the idea that anyone could actually compose code while sitting in sexual proximity with someone else, I can’t fathom this at all.