Alright, I get it. It’s fair to read this and respond, “the method isn’t wrong, you used it wrong.” And look, I don’t have a ton of experience, and I did post an opinion on the internet, so..fair. But I feel like that’s too easy. I didn’t dive too much into the incident because it was frankly long and confusing, but if readers are going to try to pin it on that, then let’s dig in.
The feature WAS just a function (at least at the start). Just a simple feature flag reader. Only…it wasn’t really. See the ask was simple, so we assumed the designing it would be striaghtforward. All the function had to do was ensure that a the app switched to a different behavior when the flag was set. Simple, right? What naive fools we were, Sebastian, like lambs being led to the slaughter.
The issue was that the deeper we dug for this seemingly simple behavior, the more we realized this feature flag actually wasn’t going to do what we wanted, and then we figured out that the original ask didn’t even want a feature flag, but rather a sort of override variable set in the environment. Truthfully, the whole process took about two hours, and maybe only half an hour of that was spent writing tests. So I feel that’s inefficient, becuase all that work had to be thrown out, since in the end everything turned out to be different. Had we just waited until the dust settled, we could’ve saved the tests. We could’ve saved them! They didn’t need to die out there like that, they were innocent!
Now, you could argue that’s not really fair, since it wasn’t the test that was to blame, but a miscommunication. But that’s literally my entire point. There are so many times where confusion and miscommunication happen. I think maybe TDD is not always the best tool for the job and all I’m asking is we should maybe stop telling impressionable young Jr. Devs like myself that it is. Now, if you remove roadblocks like skill and miscommunication, I bet you TDD works pretty great. You are clearly using it every day, so there you go, that’s the only counter argument you need frankly. And I bet you can code circles around me with a blindfold on, so that might be a contributing factor as well. But what I’m saying is that just becuase it works for some people and situations, it doesn’t make it a silver bullet. And I wrote this piece because it felt like no one was being honest. They just toss in the humble brag, “Yes TDD is slow at first, but it always wins in the end due to superior code.” Lame I say. Lame.
I am unfairly saying TDD is dumb in the title, becuase this is a joke piece, so it’s hyperbole for humor (and maybe the only reason you clicked on it to disagree with me in the comments, if we’re both being honest haha). But in all seriousness, I really do think that if you’re put in a situation where TDD would work really well…you would still maybe be better off just writing the tests in tandem as you code. Plan. Code. Test. Refactor. Test. Repeat. You hit the nail on the head yourself, TDD is not just about writing tests. So, just don’t write them at the start. Do literally everything the exact same way as TDD in terms of planning, but save yourself like 20 minutes per day by not guessing and writing the perfect test afterwards. That’s it, that’s all this goofy piece is trying to say.
Does that make sense? This is a novel and it’s late but I love that people are reading my stuff and actually taking the time to write real, well thought out comments like yours, so I hope it made my vantage point a little clearer.
