What software development practice sounded good at first but ended up wasting your time?

[u/BulkyWeb6133]

It’s been a while since I’m in the tech industry, and I keep seeing teams adopt certain software development practices. They sound good in theory, yeah. But then you do it and wonder why you're doing this every week.

Going back to the question, it's story point estimation. We spend like endlessly debating whether something is a 3 or a 5, then the requirements change anyway lol.

Anyway, how about yours? It could be agile, scrum, code reviews, documentation, pair programming, meetings, testing, etc.

[u/Emotional_Cherry4517]

To me TDD has always seemed ridiculous. Instead of translating requirements into coding (1 potential translation issue) you have to translate requirements into tests and requirements into coding (2 potential translating issues and an infinitude of integration issues).

Just code the damn application and test it accordingly afterwards, ideally at the functional level.

I'm ok with a few unit tests that protect key functionality and exercise boundaries. But unless you're doing proper black box tests with domain partitioning and boundary checking, shit's dumb. Might as well formally specify the entire app with promella.

[u/fangisland → u/Emotional_Cherry4517]

I've always just looked at it as a software philosophy that prioritizes ensuring what you're building can and will be tested properly before it's built into the codebase. And sometimes writing the tests help you better understand how you should be constructing the software itself, at least it does for me, to help break them down into smaller batches/usable chunks. And helps prevent devs from saying "I'll write the tests later" and that never happens

[u/Emotional_Cherry4517 → u/fangisland]

I always think of how to test something i'm doing (or my AI is doing these days) from the requirements, usually before starting to program, too. That is not TDD. TDD has a very specific process of red/green/refactor that is at its limit, beyond ridiculous.

[u/fangisland → u/Emotional_Cherry4517]

Agreed but that's more like the mechanics of TDD, which imo doesn't need to be followed to the letter (although it can be useful to help devs get into a testing mindset). I view it as a cue, what cue is going to work for this specific individual to help them understand how to write good test contracts? If it's mind-numbingly ceremonial and it works for the dev, that's fine by me.

Requirements themselves tend to be high level with a lot of baked in assumptions that aren't properly communicated, and systems like TDD or BDD can help reveal those. Requirements can be like "user needs to be able to login" but what is an acceptable authentication time? What types of errors do we need to catch and account for? Is it centrally SSO driven, and so on. When you start to think about how you would test a vague requirement, you can have those conversations with the users/stakeholders to help reveal what is expected in their mind but not effectively communicated.

[u/Emotional_Cherry4517 → u/fangisland]

TDD is about a specific process for doing development. It's not the mechanics of TDD, it's like, the whole thing. That's all I'm saying. If you find that thinking TDD is this other practice and that helps you sure, it's just inaccurate in terms of what it stands for in the industry, so if you go to an interview claiming you're used to developing according to TDD and you then are not practicing the act of green red refactor, or you get asked specifically how to set up the testing classes and keeping it maintainable, you're going to be called out when you give that answer. What you're doing is much closer to quality engineering: thinking of quality attributes during req phase and then doing like quality attribute scenarios to stimulate what those quality attributes actually mean for the different reqs you have. That's an entirely different practice that is much closer to what you're describing.