Timeline for Is this limitation of Test Driven Development (and Agile in general) practically relevant?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 10, 2017 at 18:11 | comment | added | JacquesB | @FrankPuffer: If you take a metric like lines of code the I believe the answer to your original question is yes: A refactoring might involve first writing some new code and then removing some old code, so the metric would be worse between the two points. | |
| Jan 10, 2017 at 17:24 | comment | added | Andres F. | @JacquesB But it's often touted that way. Explanations usually pay lip service to the notion that TDD doesn't replace thought, but in practice it looks as if it did. Again, I refer you to Ron Jeffries' extremely clumsy attempt at evolving a Sudoku solver, which you can google. It's embarrassing. TDD just doesn't work for this kind of problem, when the solver itself is unknown. And Ron Jeffries is a prominent agilist and TDD proponent, not a random newbie. | |
| Jan 10, 2017 at 16:40 | comment | added | Frank Puffer | @JacquesB: Yes, why not lines of code? You probably know that there are better ones. And all of these are very limited for sure. But they are somehow correlated to code quality when applied to pieces of software that are written in the same language and fulfill the same tests. And again, each model is a simplification and must not be mixed up with the real thing. | |
| Jan 10, 2017 at 16:28 | comment | added | JacquesB | @FrankPuffer: Depending on metrics...of course. But what are those metrics? Lines of code? | |
| Jan 10, 2017 at 16:14 | comment | added | Frank Puffer | @JacquesB: You could calculate a value based on various software metrics for one implementation. Then you define a set of refactorings, apply all of them to the original implementation and calculate the value for each of these modifications as well. If all refactorings produce a worse value, the original implementation is a local optimum. Very limited of course, depending on the metrics and the set of refactorings considered, but probably better than nothing. | |
| Jan 10, 2017 at 16:03 | comment | added | JacquesB | @FrankPuffer: OK, so what measurable value is it that has a "local optimum" in software development? | |
| Jan 10, 2017 at 16:01 | comment | added | JacquesB | @AndresF.: TDD does not mean you don't have to think or design. It just means you write the test before you write the implementation. You can do that with algorithms. | |
| Jan 10, 2017 at 15:51 | comment | added | Frank Puffer | Two remarks: (1) You are right that this can be deceiving. But I didn't write that TDD is the same as mathematical optimization. I just used it as an analogy or a model. I do believe that math can (and should) be applied to almost everything as long as you are aware of the differences between the model and the real thing. (2) Science (scientific work) is usually even less predictable than software development. And I would even say that software engineering is more like scientific work than like a craft. Crafts usually require much more routine work. | |
| Jan 10, 2017 at 13:49 | comment | added | Andres F. | [1] In fact, I'm pretty sure fibonacci, which I've seen used as a TDD example/tutorial, is more or less a lie. I'm willing to bet nobody ever "discovered" fibonacci or any similar series by TDD'ing it. Everyone starts from already knowing fibonacci, which is cheating. If you try to discover this by TDD'ing it, you'll likely reach the dead-end the OP was asking about: you'll never be able to generalize the series by simply writing more tests and refactoring -- you must apply mathematical reasoning! | |
| Jan 10, 2017 at 13:47 | comment | added | Andres F. | But was it too strong a reaction? It certainly helps in a lot of cases where strict upfront planning proved unwieldy and costly. However, some software problems must be tackled as a mathematical problem and with upfront design. You cannot TDD them. You can TDD the UI and overall design of Photoshop, but you cannot TDD its algorithms. They are not trivial examples like deriving "sum" or "double" or "pow" in typical TDD examples [1]). You probably cannot tease a new image filter out of writing some test scenarios; you absolutely must sit down and write and understand formulae. | |
| Jan 10, 2017 at 13:14 | history | answered | JacquesB | CC BY-SA 3.0 |