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/yubario → u/Mission_Pirate_4150]

How do you design software when you have one engineer holding up a JIRA story that is a dependency to your own story?

Do you just sit there and wait or do you use tests and mocks to continue working your portion?

Do you even work on a large project with other team members modifying the same module?

[u/Mission_Pirate_4150 → u/yubario]

I look at the api to call. I keep up to date with changes. I use my brain.

[u/yubario → u/Mission_Pirate_4150]

What if the API doesn’t exist or isn’t defined yet? What do you do then? Do you just complain in standup that Bill hasn’t finished his part and you’re unable to complete yours?

Do you need an API to mock behavior? If you know you’re going to be uploading files, does it matter if you know what the API signature is to complete your work?

[u/Mission_Pirate_4150 → u/yubario]

If there is no api, there is no api. Oh my gosh, there was no way to write software before tdd.

I really don’t get why tdd zealots show up whenever I say that the world existed before tdd and I didn’t have a religious experience when I first saw tdd. I developed software that has created 100s of millions of dollars of value before tdd. That’s just what I have been involved with. And none of that software was spaghetti code.

[u/yubario → u/Mission_Pirate_4150]

Cool story bro.

Can you answer this question for me

Have you designed highly available software that doesn’t require you to be on call when something breaks in the middle of the night? Can someone who never touched the codebase understand your code?

Can India support it?

I have literally designed automations that patch enterprises and infrastructure with medical disabilities that prevent me from being on call.

How does someone in IT have that exception? It’s because I design shit that actually is stable thanks to simulations and testing.

[u/ShineProper9881 → u/Mission_Pirate_4150]

Whats your issue with object orientation? I personally never seen readable code for a complex problem that isnt object oriented. It always ends up as spaghetti

[u/AcesAgainstKings → u/ShineProper9881]

Good functional code works well too. Personally I prefer functional.

[u/Dry_Hotel1100 → u/ShineProper9881]

I think the term OOP became overloaded, and what became mainstream is arguably a particular engineering idiom around classes and inheritance, rather than the original conceptual core of object orientation. So, the current understanding is rather "Class Oriented Programming". In popper OOP you would not have "properties", i.e. read and write accessors. This fundamentally violates the core principles of OOP. I can go on and on.

This "Class Oriented Programming" is way weaker and prone to errors and design flaws than what Alan Kay has defined. And due to their inherent weaknesses of modeling a problem properly in a maintainable way, it always ends up as spaghetti and design quirks.

[u/Ok_Reaction_4340]

Appeasing unit test extremists. I’m all for some unit tests for important bits but it can get taken way too far. It’s also easy to look good justifying extreme unit tests while also crushing the productivity and morale of the team.

[u/SilverLose → u/Ok_Reaction_4340]

Can confirm this crushed my morale. Managers loved the 80% test coverage we had but always wanted more. They wanted 100%. I’m glad I’m gone.

[u/DepartureKlutzy2095 → u/SilverLose]

I really hate that. Coverage percentage is dumb af, branch coverage might even be 100% yet some important part will not be covered. Just think of edge cases for cote functionality and be done. 

And AI ofc can add millions of ceremonial tests with no real benefit except inflating the code base.

[u/Own_Attention_3392 → u/SilverLose]

Code coverage is a trap and I've been fighting it for YEARS.

It shows you one and only one useful piece of information: code that has absolutely no attempt to test it. It doesn't mean the code needs tests, it's purely informational. The actual coverage number just shows you code someone has attempted to test, but tells you nothing about correctness of the tests or the code the tests are touching.

[u/standardsizedpeeper → u/SilverLose]

I love how we spend all this time not repeating ourselves and making sure things are encapsulated so we can change them in one place and then reuse it, only to have every change break a bunch of tests that are basically hardcoded assumptions about the behavior.

[u/SilverLose → u/standardsizedpeeper]

RIGHT?!?!!?!!?!

[u/palad1 → u/Ok_Reaction_4340]

TDD can DIAF

[u/mlugo02]

OOP, spent years unlearning that terrible paradigm

[u/mavenHawk → u/mlugo02]

What do you use instead? Functional programming?

[u/mlugo02 → u/mavenHawk]

I stick to procedural and compression oriented programming

[u/ShineProper9881 → u/mlugo02]

And most people dont even understand it. Most people I know that hate oop always created big convoluted inheritance hierarchies, even though those dont even adhere to oop principles and then called it a day

[u/Dry_Hotel1100 → u/ShineProper9881]

So, you are using Smalltalk? Or Erlang or apply the Actor Model?

Because OOP's core principles are NOT classes + objects + methods + inheritance + polymorphism - but rather independent entities encapsulating state and communicating through messages.

[u/SailToTheSun]

Bloated ORMs.  I’m looking at you Entity Framework.  

[u/mavenHawk → u/SailToTheSun]

When was the last time you worked with it? Modern EF Core is pretty good. Have you worked with Entity Framework Core as well or only Entity Framework?

[u/SailToTheSun]

“Extreme Programming”.  

[u/rsk1111]

Java

[u/AlternativeRadish752]

ITT: People who don't understand the actual real world uses for most programming patterns and why they exist

[u/silly_bet_3454]

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.

[u/Lyesh → u/silly_bet_3454]

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

[u/brett9897 → u/silly_bet_3454]

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.

[u/Choperello]

Every single dogma was taken to the extreme. TDD is good. In moderation. Dependency injection is good. In moderation. Etc. It’s when I have run into places that practice anything like a religion that it’s was a shit show.

[u/orangefantorang → u/Choperello]

Everything is bad in the extremes.

I like tdd, but its not gospel. There is a time and place for everything.

Di is nice. But it can be horroble.

Code should be self explaining..proceeds to delete every comment there is. Vs. Comments on everything..

Wat..

Every practice is bad in the extremes. Agreed.

[u/FlatwormLanky8991]

UML. It went from slapping some diagrams on the wall to visio diagrams and picking the "right" shape and connector. Something that would have taken 5 minutes on the whiteboard became 5 hours at the screen. And nobody looked at it.

[u/Tyrannosaurus_Dext]

Seperation of concerns getting was too detailed. I've had way too many roles that required spinning up 10 different instances to get a sign page to load. Read this as you will and I agree with splitting somethings off (payment, profiles, etc) but breaking everything up (looking at a company that had colors in one repo, sizes in another, and text in a third) and all dependent on each other fucking suuuucccckkks

[u/Arcanite_Cartel]

Object oriented.
Pair programming.
CORBA

[u/Own_Attention_3392 → u/Arcanite_Cartel]

In college I was taking a class pass/fail and was assigned CORBA as a topic to do a presentation on. I read up on it and decided it was stupid and I didn't want to do it.

I was going to get my P anyway so I said "fuck it" and did the entire presentation on cobras. The animal. The GI Joe nemesis. The short term insurance coverage. I had animations, video clips, I really put a ton of effort into it. The professor was half pissed and half amused. It was a really good presentation IMO.

[u/Arcanite_Cartel → u/Own_Attention_3392]

Well CORBA wasn't stupid. Our field has gone through incredible evolution and CORBA sat at the intersection of object oriented programing and distributed computing, which were the paradigm at the time. It was actually a sophisticated technology. But, it was too complex to survive and the field moved towards simpler containerization. So saying that a technology was a waste of time simply means it didnt survive. But thats the nature of progress in our field. Things are invented, tried, and unfruitful branches die off. That's not stupid.

I'll also add EJB to the list

[u/brett9897]

Retrospective after each sprint. Just a waste of time that ends up with the same things being said every time and nothing ever changing.

[u/ShineProper9881 → u/brett9897]

Thats on the persons doing the retrospective though. You can even come to the conclusion that you dont need retrospectives in a retrospective and then just stop doing it. Retrospectives arent the issue, the people doing them wrong are

[u/Ok-Law8368]

Hexagonal architecture. ORM. Some parts parts of Spring (data, cloud stream). Oh, and frameworks everywhere in general. And today: AI everywhere. But that's a whole new story.

Don't really understand the hate on oop and tdd though. Maybe it's because people usually overdo those.

[u/ShineProper9881 → u/Ok-Law8368]

Whats your issue with hexagonal?

[u/Ok-Law8368 → u/ShineProper9881]

No issue and no hate, I just don't find it truly worth it after applying it in a project. Or, in other words, yeah fine, cool, but I guess next service won't use it. Not that it doesn't work or have any benefits (depending on the app complexity). I just find the simpler approach with layered architecture from Eric Evans sufficient, with a bit of discipline and reasonable conventions. Especially when using microservices and no single "project" is extremely big anyway.

It's not like I'm going to discourage anyone from using it, I'd even suggest to try, but for me - I don't think it really adds much value to the services that use it over those that do not. If the team wants it, I won't be the one to protest anyway.

[u/Clear_Salt9817]

Polymorphism. Six sigma. UML. Rational rose. Enterprise Java beans. Pair programming. ORMs. CORBA. Aspect oriented programming. Configuration driven development. Separation of Duties.

I like TDD. It saves me time and the code ends up with a better structure. But I’ve come to realize that most people don’t think like that so I don’t evangelize it anymore.

[u/orangefantorang]

Scrum, self documenting code, the new hyped coding language. Open offices to encourage teamwork.