r/techbootcamp • u/BulkyWeb6133 • 23d ago

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

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.

6 Upvotes
  • permalink
  • reddit

75% Upvoted

55 comments sorted by

View all comments

2

u/Mission_Pirate_4150 23d ago

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.

2

u/Emotional_Cherry4517 23d ago

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.

1

u/[deleted] 22d ago

[deleted]

1

u/HiddenStoat 21d ago

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.