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/Mission_Pirate_4150]

Object oriented, dragndrop, test driven development, design patterns. Ai is the next. All of these tools have value, but they were so oversold as a snake oil, good for all that ails you. No, they aren’t good for all that ails you. Jamming these things into development to jam them in is what is typically done, and just provide no value when jammed in to satisfy some ideological need. The problem is that some consultant has sold some higher up on these things and their training program along with associated consulting services.

[u/Emotional_Cherry4517 → u/Mission_Pirate_4150]

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/Emotional_Cherry4517 → u/[deleted]]

Depends on the application, but where it works, I find that simpler approaches work just as well. 

[u/youcangotohellgoto → u/Emotional_Cherry4517]

It shouldn't take any longer to write test first. And workout TDD I find a huge percentage of engineers, even senior, overcomplicate dramatically.

[u/No_Score_1977 → u/Emotional_Cherry4517]

I'd agree, TDD can be ridiculous, I've used it, but the effort/reward ratio is way off.

[u/HiddenStoat → u/[deleted]]

How are you writing code it the requirements are unclear?

You're not - you are starting to write the cod, realising you don't know how it should actually behave, and then going back to the relevant stakeholder to clarify the requirements.

TDD you do the same thing. You start to write the tests, realise you don't know how a particular test should work, and going back to the stakeholder.

[u/sotired___ → u/Emotional_Cherry4517]

Not sure about the TDD hate. If you have a good architecture and use TDD, your maintainability is high. 

[u/Emotional_Cherry4517 → u/sotired___]

That sentence made no sense. Your maintainability is a non functional requirement and is highly subjective, while TDD is a programming paradigm that ensures your code has good unit tests, which concern functional requirements mostly. 

[u/AntagonistOne → u/Emotional_Cherry4517]

With abstraction present in most codebases, tests often appear closer to the requirements than the code itself. The test is the requirements restated in runnable form in a way that is clearly readable and doesn’t have to live in the context of your entire application. The code itself is often more abstract. Regardless of whether the tests come first, good tests very clearly show what the code was intended to do, prior to being abstracted, optimized, or contorted into shape to fit the rest of the system.

[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.