My feelings are far less complicated: TDD is a high-discipline approach to software development, and that's why it doesn't work or doesn't get done.
High-discipline meaning, it entirely depends on highly competent developers (able to produce clean code, deep understanding of programming), rigorously disciplined out of pure intrinsic motivation, and even able to do this under peak pressure.
Which is not at all how most software is built today. Specs are shit so you gradually find out what it needs to do. Most coders are bread programmers and I don't mean that in any insulting way. They barely get by getting anything to work. Most projects are under very high time pressure, shit needs to get delivered and as fast as possible. Code being written in such a way that it's not really testable. We think in 2 week sprints which means anything long term is pretty much ignored.
In such an environment, the shortest path is taken. And since updating your tests is also something you can skip, coverage will sink. Bugs escape the test suite and the belief in the point of TDD crumbles. Like a broken window effect.
My point is not against TDD. It's against ivory tower thinking that does not take into account a typical messy real world situation.
I've noticed a major shift in the last decade. We used to think like this, in TDD, in documenting things with UML, in reasoning about design patterns. It feels like we lost it all, as if it's all totally irrelevant now. The paradigm is now hyper speed. Deliver. Fast. In any way you can.
This short-sighted approach leading to long term catastrophe? Not even that seems to matter anymore, as the thing you're working on has the shelf life of fish. It seems to be business as usual to replace everything in about 3-5 years.
High-discipline meaning, it entirely depends on highly competent developers (able to produce clean code, deep understanding of programming), rigorously disciplined out of pure intrinsic motivation, and even able to do this under peak pressure.
Which is not at all how most software is built today. Specs are shit so you gradually find out what it needs to do. Most coders are bread programmers and I don't mean that in any insulting way. They barely get by getting anything to work. Most projects are under very high time pressure, shit needs to get delivered and as fast as possible. Code being written in such a way that it's not really testable. We think in 2 week sprints which means anything long term is pretty much ignored.
In such an environment, the shortest path is taken. And since updating your tests is also something you can skip, coverage will sink. Bugs escape the test suite and the belief in the point of TDD crumbles. Like a broken window effect.
My point is not against TDD. It's against ivory tower thinking that does not take into account a typical messy real world situation.
I've noticed a major shift in the last decade. We used to think like this, in TDD, in documenting things with UML, in reasoning about design patterns. It feels like we lost it all, as if it's all totally irrelevant now. The paradigm is now hyper speed. Deliver. Fast. In any way you can.
This short-sighted approach leading to long term catastrophe? Not even that seems to matter anymore, as the thing you're working on has the shelf life of fish. It seems to be business as usual to replace everything in about 3-5 years.
The world is really, really fast now.