I see value in the TDD content - as you say, there is still a lot of wrong out there. Explaining in different ways helps improve the likely hood of adoption or at least trying it.
This is the first I have come to realize that some are thinking of TDD as a way to avoid doing design. Thank you for posting this as it will make me more aware of how colleagues may be misunderstanding it. TDD in my view is simply a validation of implementation but if you use it to iterate to a design, you will end up doing a lot of duplicative work when you finally realize you need to redesign for the interface you need. There is a feedback loop for sure though. Keep sharing the TDD info!
I never introduce TDD to the teams I'm coaching as something that could improve the design. I found out that it's largely a losing proposition to claim such things. If I do that, we end up going in circles with endless equivocations. In the end, everyone just loses interest, and the momentum is lost, and with it the opportunity to try something new and exciting.
Instead, I introduce TDD as a time saving technique. I'm always like "look, if some newfangled approach is not going to save me time, why would I even bother?" I find that such an approach tends to work better, as it makes people sit up and listen. Who doesn't want to save some time and avoid the drudgery?
And indeed, when teaching TDD by placing the time saving aspect front and centre, I'm noticing that TDD is gaining much better traction among novices and old hands alike. People get easily attracted to anything that will get them to the end of the workday sooner, with less exhaustion. As such, TDD is a technique/discipline that is proving remarkably efficient. And so what if it didn't necessarily lead us to the best possible design? Isn't design a separate concern anyway?
By ZERO decisions, do you mean ZERO during the process of initial TDD; you're just getting started? I'm thinking yes, because we have to make a lot of design decisions to make production quality code. But, we may not even think about designs until we have a tiny thing working. e.g. Maybe I want to send a message across the network, to prove I can connect to an existing service. I'm uncertain what the design will be, so I want to use TDD to experiment what that might look like. Once I know how it's working, I'll make some decisions on a good interface to that service of sending a message.
It has always paid off to me to think of what exactly do I want to do before I actually start to code. Well, not exactly, but still having sense on what do I want to create. I have plenty of tools at hand, including basic set of design patterns.
One thought about TDD that I am having lately, it is not related to the topic of this Substack, anyway I fell that this is a good place to comment about it, let me know if there is a post/thinkie/article about it already.
Writing the code before the tests will bring some results beforehand (not the final one), and that will motivate me to keep developing for the next minutes/hours/days, including refactoring, testing, and probably redesigning. It is just the natural behavior of humans to seek rewards to continue motivated. At the end I might spend some time refactoring it, but I fell more likely that it will be started sooner and probably finished sooner (since I have started it looking for that fast reward).
When I commit to coding the tests before developing, it obligates me to think about the design, input, and output structure. It will force me to think deeper about the problem, even though multiple times I am not confident enough about it. Rationally, I see that it will give me more confidence and a better design since the beginning. However, personally, I postpone the start of this task way further then when I do not use TDD.
However, I believe that by consistently practicing TDD, my reward perception might shift from valuing quick results to prioritizing better design upfront. Do you think that practicing TDD can change my reward perception, or will it just be my rational and experienced side taking more control over that instant dopamine-seeking side?
Giving a bit more context, I have been working more on a personal project, in which I have total control over balancing delivery dates, scope, and quality. That is where these thoughts are coming from. Professionally, I am now primarily managing, rather than coding. Previously, when I coded daily, I worked in companies without a strong TDD culture.
There's a pattern here. Not a design pattern or a thinkie pattern, but a debate/discussion/idea-interchange pattern. It's often called "strawman" and it can be insidious. In this case, I don't think it was utilized intentionally or maliciously (although it often is), but it's important to recognize it and call it out so it doesn't grow or redirect the discussion and exchange of ideas in a way that reduces _productive_ discussion and exchange of ideas.
Intellectually honest people probably don't use the pattern that way, and get frustrated by it.
I see value in the TDD content - as you say, there is still a lot of wrong out there. Explaining in different ways helps improve the likely hood of adoption or at least trying it.
> Let me know if you’re getting tired of TDD-related content.
Nope, I don't think I'll ever get tired of it!
This is the first I have come to realize that some are thinking of TDD as a way to avoid doing design. Thank you for posting this as it will make me more aware of how colleagues may be misunderstanding it. TDD in my view is simply a validation of implementation but if you use it to iterate to a design, you will end up doing a lot of duplicative work when you finally realize you need to redesign for the interface you need. There is a feedback loop for sure though. Keep sharing the TDD info!
I never introduce TDD to the teams I'm coaching as something that could improve the design. I found out that it's largely a losing proposition to claim such things. If I do that, we end up going in circles with endless equivocations. In the end, everyone just loses interest, and the momentum is lost, and with it the opportunity to try something new and exciting.
Instead, I introduce TDD as a time saving technique. I'm always like "look, if some newfangled approach is not going to save me time, why would I even bother?" I find that such an approach tends to work better, as it makes people sit up and listen. Who doesn't want to save some time and avoid the drudgery?
And indeed, when teaching TDD by placing the time saving aspect front and centre, I'm noticing that TDD is gaining much better traction among novices and old hands alike. People get easily attracted to anything that will get them to the end of the workday sooner, with less exhaustion. As such, TDD is a technique/discipline that is proving remarkably efficient. And so what if it didn't necessarily lead us to the best possible design? Isn't design a separate concern anyway?
There's never enough TDD content. I'm here for it. I preach it. I worship at the Church of TDD.
Are you basically saying that TDD helps define and proof the "contract" (another word for interface) as it's being developed?
By ZERO decisions, do you mean ZERO during the process of initial TDD; you're just getting started? I'm thinking yes, because we have to make a lot of design decisions to make production quality code. But, we may not even think about designs until we have a tiny thing working. e.g. Maybe I want to send a message across the network, to prove I can connect to an existing service. I'm uncertain what the design will be, so I want to use TDD to experiment what that might look like. Once I know how it's working, I'll make some decisions on a good interface to that service of sending a message.
It has always paid off to me to think of what exactly do I want to do before I actually start to code. Well, not exactly, but still having sense on what do I want to create. I have plenty of tools at hand, including basic set of design patterns.
One thought about TDD that I am having lately, it is not related to the topic of this Substack, anyway I fell that this is a good place to comment about it, let me know if there is a post/thinkie/article about it already.
Writing the code before the tests will bring some results beforehand (not the final one), and that will motivate me to keep developing for the next minutes/hours/days, including refactoring, testing, and probably redesigning. It is just the natural behavior of humans to seek rewards to continue motivated. At the end I might spend some time refactoring it, but I fell more likely that it will be started sooner and probably finished sooner (since I have started it looking for that fast reward).
When I commit to coding the tests before developing, it obligates me to think about the design, input, and output structure. It will force me to think deeper about the problem, even though multiple times I am not confident enough about it. Rationally, I see that it will give me more confidence and a better design since the beginning. However, personally, I postpone the start of this task way further then when I do not use TDD.
However, I believe that by consistently practicing TDD, my reward perception might shift from valuing quick results to prioritizing better design upfront. Do you think that practicing TDD can change my reward perception, or will it just be my rational and experienced side taking more control over that instant dopamine-seeking side?
Giving a bit more context, I have been working more on a personal project, in which I have total control over balancing delivery dates, scope, and quality. That is where these thoughts are coming from. Professionally, I am now primarily managing, rather than coding. Previously, when I coded daily, I worked in companies without a strong TDD culture.
There's a pattern here. Not a design pattern or a thinkie pattern, but a debate/discussion/idea-interchange pattern. It's often called "strawman" and it can be insidious. In this case, I don't think it was utilized intentionally or maliciously (although it often is), but it's important to recognize it and call it out so it doesn't grow or redirect the discussion and exchange of ideas in a way that reduces _productive_ discussion and exchange of ideas.
Intellectually honest people probably don't use the pattern that way, and get frustrated by it.