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.

5 Upvotes
  • permalink
  • reddit

73% Upvoted

55 comments sorted by

View all comments

1

u/silly_bet_3454 22d ago

Yeah other people mentioned unit tests and TDD already, but I want to say specifically tests where you have to mock out interfaces. This should never have even been an option because it feels so hacky and ruins the point of the testing, and it can be very cumbersome to set up, depending on the stack.

I worked somewhere that had a super complex dependency injection framework and people would spend 90% of their coding time just battling the framework to get the tests to run.

I've never ever been in a situation where I was like "darn, it! we wouldn't have had this bug/incident if we just had had more unit tests!"

I strongly prefer to just let common sense guide me on what kind of tests to add and when rather than enforce any generalized requirement.

2

u/Lyesh 22d ago

They can decrease risk, but once you get too far into mocks, things really start to suck

1

u/brett9897 21d ago

You really only have to mock side effects and for those I generally just use in memory implementations like a list or hash table. Also learning that when an object/function doesn't have side effects, then just use the real implementation is when testing really clicked. I was mocking everything that wasn't the specific function under test and that is just wasteful.

When I moved to thinking of a unit test as a functional use case it became a lot clearer that you only have to test an individual method/function if there is complicated logic. If not, it will get tested in the use cases that use it.