This is pretty much the whole point of test-driven development. Once the tests are the authoritative source of truth for what the code is supposed to do, knowledge of the system in the mental-model sense becomes almost superfluous: all a buck-newbie coder needs to do is find out why some test failed and make it pass. Of course you can't sneeze without writing (perhaps lots of) test code, but hey, the company's stock price is no longer beholden to snobbish devs who monopolize the mental models of the code. Hallelujah!
Like open-plan offices, the benefits to management of TDD cannot be overestimated when considering what drove its adoption.
Also I get the feeling this guy has never read The Mythical Man-Month. Top-down development following a strict waterfall model? Brooks shows that even inside stodgy IBM, no one did that if they wanted to get work done (as opposed to producing reams of paperwork in order to satisfy auditors and assure them that work is getting done).
Like open-plan offices, the benefits to management of TDD cannot be overestimated when considering what drove its adoption.
Also I get the feeling this guy has never read The Mythical Man-Month. Top-down development following a strict waterfall model? Brooks shows that even inside stodgy IBM, no one did that if they wanted to get work done (as opposed to producing reams of paperwork in order to satisfy auditors and assure them that work is getting done).