In my experience, it's not the fact that TDD is "unintuitive" that prevents people from doing it, it's that folks generally don't like to do things differently (especially if they've become competent or expert, and become a novice again) unless there's a compelling reason to do so. TDD is not a "quick win" where we can easily demonstrate its superiority.
Learning to ride a bicycle might be hard because it's unintuitive (though I don't think intuition is a useful term for that kind of learning as it relates to biologically primary learning), people try it and learn how to do it anyway because they _want_ to.
I'd also say that automated developer tests (first or last) are probably not "intuitive" to many, as they often didn't learn to write tests until after they were already capable of coding. So learning to write tests at all (instead of manually testing or sitting in the debugger) is unintuitive for them.
btw, I don't see the "test after" intuition coming from medical or cooking (it's an interesting analogy, but not one I have ever heard before). I see it as "that's how I've always done it", and it generally "works for me", and therefore it becomes part of their expertise (and then perhaps their identity).
Well written article. I like it. There is also another angle one can take though, that my be easier for some to digest.
When we test something, or rather check something (the test is really just an automated checker), we need to know what we’re checking for. TDD is a way to define what we’re check for up front, in small incremental steps. In other words, it’s about defining what the code should do before we create the code that does it. From that viewpoint it may feel a bit more natural.
In my experience, it's not the fact that TDD is "unintuitive" that prevents people from doing it, it's that folks generally don't like to do things differently (especially if they've become competent or expert, and become a novice again) unless there's a compelling reason to do so. TDD is not a "quick win" where we can easily demonstrate its superiority.
Learning to ride a bicycle might be hard because it's unintuitive (though I don't think intuition is a useful term for that kind of learning as it relates to biologically primary learning), people try it and learn how to do it anyway because they _want_ to.
I'd also say that automated developer tests (first or last) are probably not "intuitive" to many, as they often didn't learn to write tests until after they were already capable of coding. So learning to write tests at all (instead of manually testing or sitting in the debugger) is unintuitive for them.
btw, I don't see the "test after" intuition coming from medical or cooking (it's an interesting analogy, but not one I have ever heard before). I see it as "that's how I've always done it", and it generally "works for me", and therefore it becomes part of their expertise (and then perhaps their identity).
Well written article. I like it. There is also another angle one can take though, that my be easier for some to digest.
When we test something, or rather check something (the test is really just an automated checker), we need to know what we’re checking for. TDD is a way to define what we’re check for up front, in small incremental steps. In other words, it’s about defining what the code should do before we create the code that does it. From that viewpoint it may feel a bit more natural.