3 ms·

I think the problem with TDD is it assumes you know what shape your functions and classes and data structures will take before you start coding. This is rarely

by tus88 7y ago

I think the problem with TDD is it assumes you know what shape your functions and classes and data structures will take before you start coding. This is rarely the case, and if it were easy then CASE tools would have won over the world in the 90s. They didn't and people still code in typeless scripting languages. I think it's this glossing over the inherent and deep complexity of software development that turns a lot of people off TDD. What's wrong with getting the software right, often through a process of trial and error, and then writing the tests to lock in what you have working?

cjfd 7y ago
"TDD [...] assumes you know what shape your functions and classes and data structures will take before you start coding". Absolutely not. In a green field project you might start TDD with an 'architecture' consisting of only one function. Since one single function is a very bad architecture for anything except something extremely simple at some point refactoring would take that function into multiple functions, or make a class of it or do yet something else. The main difference with the CASE approach is that TDD does not presume that we can know an adequate architecture beforehand but instead can figure that out while we are going. I.e., decide things when we actually have the information to do it. TDD actually is the only method of software development that I know of that respects the complexities involved in software development. One might write test afterwards but as I note above tests do cost time so one should aim for the maximum payback of that time. When you start with the test it starts paying back as soon as possible starting from the point where it flags your first attempt making the test pass as not quite working. One case where it may be better to start with some trial and error is when it is not clear what algorithm should be used.

by tus88 7y ago

cjfd 7y ago

"TDD [...] assumes you know what shape your functions and classes and data structures will take before you start coding". Absolutely not. In a green field project you might start TDD with an 'architecture' consisting of only one function. Since one single function is a very bad architecture for anything except something extremely simple at some point refactoring would take that function into multiple functions, or make a class of it or do yet something else. The main difference with the CASE approach is that TDD does not presume that we can know an adequate architecture beforehand but instead can figure that out while we are going. I.e., decide things when we actually have the information to do it. TDD actually is the only method of software development that I know of that respects the complexities involved in software development. One might write test afterwards but as I note above tests do cost time so one should aim for the maximum payback of that time. When you start with the test it starts paying back as soon as possible starting from the point where it flags your first attempt making the test pass as not quite working. One case where it may be better to start with some trial and error is when it is not clear what algorithm should be used.