|
|
|
|
|
|
by joe_the_user
5671 days ago
|
|
|
What is the source of your confidence? Do you have evidence for this? TDD advocates make assertions based on a certain common sense ("tests are scaffolding") but I don't see the present evidence supporting such assertions. The thing is that TDD also often calls for not spending a lot of time on "Big, upfront design". I could just as easily argue that without a coherent design, your next iteration is going to be longer and that the critical thing is to master good design principles. But that belief also needs evidence behind it. Programming is ultimately a mysterious thing and so looking at real, long term data is good, especially after you become good enough that everything seems clear to you. |
|
|
You could argue that without a coherent design, your next iteration is going to be longer. I'd argue the reverse - but it depends on what you mean by "big upfront design"
Every program, TDD or not, needs to get a basic architectural outline in place early on - e.g. decide if you're building a web app or a desktop client, which framework you'll use to build it. Usually you have a good idea of a lot of other major pieces of that you want in your architecture - they're there in "best practices" such as SOLID, repository pattern, CQRS, MVVM, etc. TDDs encourages "spikes" that prove the concept with a vertical slice through all layers of the app.
In my opinion and experience, "Big, upfront design" is a 1980s-1990s idea that all details of the program, not just the outlines, can be designed once before coding commences. And it is a completely false idea. TDD and agile say that you're going to redesign anyway, so you may as well accommodate that. This is where TDD speeds things up. Change is not just adding things to a program, it involves redesign on existing parts.
But I agree that an ounce of data is better than a pound of theory in this case. And number are far better than anecdote. That's what the article is for, I guess we should be reading it.