Someone said on HN a while back that this sort of approach is the most sensible, because any design doc is just an incomplete abstraction until you get in the weeds to see where all the tricky parts are. Programming is literally writing plans for a computer to do a thing, so writing a document about everything you need to write the plan is an exercise in frustration. And if you DO spend a lot of time making a perfect document, you've put in far more work than simply hacking around a bit to explore the problem space. Because only by fully exploring a problem can you confidently estimate how long it will take to write the real code. Often times after the first draft I just need to clean things up a bit or only half complete a bad solution before improving it. Yes, there are times you need to sit and have a think first, but less often than you might imagine.
Of course, at a certain scale and team size a tedious document IS the fastest way to do things... but god help you if you work on a shared code base like that.
I've always thought the rigid TDD approach and similar anti-coding styles really lend themselves to people that would rather not be programming. Or at least have a touch of the OCD and can't stand to not have a unit test for every line of code. Because it really is a lot more work both up front and in maintenance to live that way.
Cyber-paper is cheap, so don't be afraid to write some extra lines on it.
TDD is being done in weird ways by lots of people from what I've seen. I always understood the book's advice to never write code without a test as both aspirational, and productivity advice, not a hard rule.
My first job predated (at least our knowledge of) TDD and unit test frameworks. We would write little programs that would include some of our code and exercise them a bit during development. Later when everything was working and integrated, we'd throw it away. I believe that used to be called scaffolding (before Rails gave that term a different meaning).
When I got into unit testing and some degree of TDD a while later, I kinda kept the same spirit. The unit tests help me build the thing without needing ten steps to test that it works. Sure, I keep the tests, but primarily as documentation on how the parts of the system that are covered should behave. And when it's significantly easier to test something manually than to write a unit test, I tend towards that.
In languages that have good REPLs, I tend to write fewer tests, cause they function as a universal test scaffold.
Trying to reach 100 % test coverage and using unit tests for QA strikes me as strange. They're at most useful to quickly detect regressions. But most of these monster test suites become a burden over time from my experience. A pragmatic test suite rarely does. There's a lot of potential in having the right balance between unit tests, integration tests and manual testing. There's a lot of time wasted if the balance is off.
With this mindset, I totally write tests for a prototype if it looks like it'll save me time. Not even close to 100 % coverage though.
Of course, at a certain scale and team size a tedious document IS the fastest way to do things... but god help you if you work on a shared code base like that.
I've always thought the rigid TDD approach and similar anti-coding styles really lend themselves to people that would rather not be programming. Or at least have a touch of the OCD and can't stand to not have a unit test for every line of code. Because it really is a lot more work both up front and in maintenance to live that way.
Cyber-paper is cheap, so don't be afraid to write some extra lines on it.