I find it fascinating that the originator of TDD is so against this notion of documentation. Particularly since his methodology only works if you have well-defi

I find it fascinating that the originator of TDD is so against this notion of documentation. Particularly since his methodology only works if you have well-defined up-front design. But much more so than my grime of mixing principles and methodologies in the original TDD book is how he absolutely does not mention DDD. It strikes me that many programmers don't even attempt to understand a non-concrete, non-specific understanding of their programming and try to keep track of all data-flows in their mind. If your software grows at a non-trivial pace, this goes wrong every single-time (this is even the case for miracle programmers like John Carmack). Good documentation allows to reason about your application in an abstract and formal way. It serves as an orthogonal layer of understanding. But you must talk with domain experts and do some serious knowledge crunching: Understand your domain, visualize your core concepts, write down important/complex processes etc. (aka, all the things pure coding-guys don't like). And of course, maintain your domain understanding as much as you are maintaining code. "Code-only" doesn't scale, just as much as "Document waterfall" doesn't work. Call me a DDD shill, but I seriously believe it is the way for non-trivial programs. Because you know what happens if you don't have a formal understanding of your program and you invest millions into your project? Games like Starfield happen.