13 ms·

Controversial Opinion TDD for me has always been something to show off at an interview; performing a beautifully choreographed dance of "Red, Green, Refactor"

Controversial Opinion TDD for me has always been something to show off at an interview; performing a beautifully choreographed dance of "Red, Green, Refactor" when showing off your skills. TDD is only useful for me when I know the structure of my code i.e. I am fixing a bug or adding a feature to an existing application. However when you are "in the dark" or early days of developing a new service then TDD can definitely slow you down if you don't know what your architecture is going to look like (maybe thats my fault from not enough whiteboarding?)

digitalsushi 6y ago
Your last sentence is beautiful. You're on the journey. If TDD is slowing a developer down because they don't know what the architecture is, it's a strong indicator that the plan isn't complete. By the time TDD is being used, it should be as obvious what to do as unpacking a U-Haul truck full of boxes parked in front of an empty house with the door propped open.
- gridlockd 6y ago
  Yeah sure, you have your clean architecture laid out without having written a single line of code. Then you implement it and it all works out fine, on time and on budget. That's a nice fairy-tale.
  - hitekker 6y ago
    Yep, the GP's statement is completely dissonant from reality. Inverting the development process may be useful for some well understood domains, but certainly not a majority, let alone the amount TDD zealots proclaim.
- mattlondon 6y ago
  > By the time TDD is being used, it should be as obvious what to do as unpacking a U-Haul truck full of boxes parked in front of an empty house with the door propped open. <sarcasm>By the time TDD is being used, you should have already have known way ahead of time the house you were going to move to in the future and simply just had your amazon orders shipped to that address in the first place. If you have to move your boxes at all, your design was clearly incomplete originally and you should not have started buying belongings until you knew the final house you were going to live in first.</sarcasm> Real life is too messy for TDD 99% of the time I find. Unexpected things happen (e.g. you move house) that means you can't know everything ahead of time.
  - digitalsushi 6y ago
    I hear you. But I feel that saying real life is too messy for TDD 99 out of 100 times, is an appeal to fatalism. I believe, in good faith, that more often than one percent of the time, the existence of a good plan is what enables TDD to be the successful demonstration it claims to be. The trust that we grow as practitioners of good software architecture is what enables us to have these talking points. I believe that we should feel enabled to discuss how to succeed, and less so how to fail.
sixdimensional 6y ago
I think you have an opportunity to reframe TDD in your last sentence. TDD, like Agile and Scrum, is not a one size fits all solution. These are tools with process that have to be adapted to the people and the organization. That’s why the creators of these practices are declaring them “dead”, because people are blindly believing they are written in stone rules and that misses the intention. We made these rules to help ourselves and our organizations... not to overly constrain ourselves... add more discipline but leave room for flexibility that our jobs demand of us. Have you ever had to write some calling code, to call some other code, to make sure it worked? Don’t call it a formal test, I mean, a chunk of code that calls your other code, and you verify that the expected output is what you thought it would be? Coding is often a process of discovery. Architecture can be learned but applying it takes discovery and iteration. “Why do I need a certain architecture?”. Well, if you don’t know, code long enough, and do enough projects, and you might start discovering architecture all on your own. Then you might see how what you discover aligns with what others have discovered. Writing code can help you discover the right architecture, as long as you keep trying and keep iterating. Many of us had to learn and discover everything on the job, because not everything was known - much of it was being invented and discovered while we coded. Is that as efficient as learning known patterns and applying them? Maybe not, but also I believe the only way you can truly internalize the knowledge of a pattern or architecture is by implementing it, even when you don’t fully understand it. Therefore, you need to “test” it out to explore and discover it, to internalize it, to really learn and understand it. TDD in that respect can simply be seen as a helpful crutch to help you, as you explore, discover, iterate and learn. A “test”, whether it be a unit or integration test, is that chunk of code that calls some other code, so you can see if the other code works or not, especially in a mocked up context of how you think it should work later. TDD is just accepting at the beginning, “I only have a rough idea of what this should do, I’ll define a starting point to call into my code, even code I haven’t written yet, so I can explore and discover both that code’s external interface and also internal implementation, and see results sooner”. Using TDD is like sketching the blueprint of how you think the architecture should work, or how you want it to work, and then trying to color in the code in the middle, to see if it really does work. TDD isn’t an absolute. It’s just a helpful practice made by developers to try to help developers... and you will eventually do something like it, even if you don’t know what it is called... because that’s how we all code in the end. Think, code, discover, test, integrate... and iterate. TDD just suggests, start in a test, and then start thinking, and then continue as usual.. and let the testing framework help you assist you as you explore and learn.

digitalsushi 6y ago

Your last sentence is beautiful. You're on the journey. If TDD is slowing a developer down because they don't know what the architecture is, it's a strong indicator that the plan isn't complete. By the time TDD is being used, it should be as obvious what to do as unpacking a U-Haul truck full of boxes parked in front of an empty house with the door propped open.

gridlockd 6y ago
Yeah sure, you have your clean architecture laid out without having written a single line of code. Then you implement it and it all works out fine, on time and on budget. That's a nice fairy-tale.
- hitekker 6y ago
  Yep, the GP's statement is completely dissonant from reality. Inverting the development process may be useful for some well understood domains, but certainly not a majority, let alone the amount TDD zealots proclaim.
mattlondon 6y ago
> By the time TDD is being used, it should be as obvious what to do as unpacking a U-Haul truck full of boxes parked in front of an empty house with the door propped open. <sarcasm>By the time TDD is being used, you should have already have known way ahead of time the house you were going to move to in the future and simply just had your amazon orders shipped to that address in the first place. If you have to move your boxes at all, your design was clearly incomplete originally and you should not have started buying belongings until you knew the final house you were going to live in first.</sarcasm> Real life is too messy for TDD 99% of the time I find. Unexpected things happen (e.g. you move house) that means you can't know everything ahead of time.
- digitalsushi 6y ago
  I hear you. But I feel that saying real life is too messy for TDD 99 out of 100 times, is an appeal to fatalism. I believe, in good faith, that more often than one percent of the time, the existence of a good plan is what enables TDD to be the successful demonstration it claims to be. The trust that we grow as practitioners of good software architecture is what enables us to have these talking points. I believe that we should feel enabled to discuss how to succeed, and less so how to fail.

sixdimensional 6y ago

I think you have an opportunity to reframe TDD in your last sentence. TDD, like Agile and Scrum, is not a one size fits all solution. These are tools with process that have to be adapted to the people and the organization. That’s why the creators of these practices are declaring them “dead”, because people are blindly believing they are written in stone rules and that misses the intention. We made these rules to help ourselves and our organizations... not to overly constrain ourselves... add more discipline but leave room for flexibility that our jobs demand of us. Have you ever had to write some calling code, to call some other code, to make sure it worked? Don’t call it a formal test, I mean, a chunk of code that calls your other code, and you verify that the expected output is what you thought it would be? Coding is often a process of discovery. Architecture can be learned but applying it takes discovery and iteration. “Why do I need a certain architecture?”. Well, if you don’t know, code long enough, and do enough projects, and you might start discovering architecture all on your own. Then you might see how what you discover aligns with what others have discovered. Writing code can help you discover the right architecture, as long as you keep trying and keep iterating. Many of us had to learn and discover everything on the job, because not everything was known - much of it was being invented and discovered while we coded. Is that as efficient as learning known patterns and applying them? Maybe not, but also I believe the only way you can truly internalize the knowledge of a pattern or architecture is by implementing it, even when you don’t fully understand it. Therefore, you need to “test” it out to explore and discover it, to internalize it, to really learn and understand it. TDD in that respect can simply be seen as a helpful crutch to help you, as you explore, discover, iterate and learn. A “test”, whether it be a unit or integration test, is that chunk of code that calls some other code, so you can see if the other code works or not, especially in a mocked up context of how you think it should work later. TDD is just accepting at the beginning, “I only have a rough idea of what this should do, I’ll define a starting point to call into my code, even code I haven’t written yet, so I can explore and discover both that code’s external interface and also internal implementation, and see results sooner”. Using TDD is like sketching the blueprint of how you think the architecture should work, or how you want it to work, and then trying to color in the code in the middle, to see if it really does work. TDD isn’t an absolute. It’s just a helpful practice made by developers to try to help developers... and you will eventually do something like it, even if you don’t know what it is called... because that’s how we all code in the end. Think, code, discover, test, integrate... and iterate. TDD just suggests, start in a test, and then start thinking, and then continue as usual.. and let the testing framework help you assist you as you explore and learn.