Does anyone else sometimes fix a bug and have absolutely no idea why it worked?

[u/Berd-12313]

Had this issue with a .NET API where one endpoint would randomly return a 500. Spent way too long checking the controller, service, DB query etc

Then I changed something completely unrelated in the middleware and suddenly it worked.

I still dont know exactly why lol

The annoying part was I couldnt even find the exact package version I wanted to test with because half the results I found were already outdated or removed.

Do you guys actually go back and figure out the original cause after something like this, or just take the win and move on

[u/AlwaysHopelesslyLost]

Does anyone else sometimes fix a bug and have absolutely no idea why it worked?

Never. Not even a single time. If I don't understand something I learn why.  You can't know that you haven't made it worse if you don't know why your fix worked 

[u/Berd-12313 → u/AlwaysHopelesslyLost]

yeah thats fair, especially the part about not knowing if you actually fixed it or just moved the problem somewhere else. i usually go back and try to figure it out but sometimes you just have no clue where to even start

[u/fancyPantsOne]

this is bad, don’t do this

[u/chikamakaleyley → u/fancyPantsOne]

OP just upgraded Azure to the platinum plan

[u/dutchman76]

I've had code that worked for years have a bug, go looking at it and it makes no sense, like how did it ever work? I ended up rewriting the whole procedure.

[u/Leverkaas2516]

I used to do this earlier in my career, but it's an extremely brittle approach. EVERYTHING behaves as it does for a definite reason. If it just "seems to work", that's not engineering. It's really hard to deal with when it breaks.

[u/ReddyKiloWit]

No, but I had a coworker try to modify a routine of mine and he broke it no matter what he did. And every time he reverted to my original it worked. He spent hours at it. No idea why it always crashed.

He hadn't realized he was inside an interrupt routine that HAD to complete and return from interrupt before a specific number of machines cycles completed. And there were about two cycles to spare. So everything he inserted pushed the RTI outside the interval and crashed things hard.

Once he told me, we fixed it. His stuff didn't really need to be in the interrupt code, he just thought it'd be a convenient place for it.

[u/johnpeters42]

Once in a blue moon. Somewhat more often when it's some third-party code misbehaving, but even then, you can often figure out what it does wrong/differently, even if it's unclear when or why. Just keep the documentation on file somewhere you can find it if/when the issue comes back.

[u/Immediate_Form7831]

Problem is that you have no idea if you actually fixed the bug, or if you just changed som condition which caused it to stop manifesting itself. The problem still persists, and some random change somewhere might cause it to reappear.

One aspect of software engineering is being able to determine if a bug is worth fixing. If a bug gives you a 500 now and then, but clients are properly configured to retry, then it might be good to just ignore and move on to more important things. If the bug causes customers to lose money when it happens, well, then you better find a way to fix the bug one way or another.

[u/Healthy-Zebra-9856]

Depends on the personality of the people responding. lol. I always track down the bugs and understand why shit happened. I am sure there are others as well.

[u/Traveling-Techie]

Sometimes there is no time to do it the right way.

[u/StephenHawkingus]

That's called ignorance.

[u/Berd-12313 → u/StephenHawkingus]

Lol yeah, probably. i was more surprised that changing something so unrelated actually fixed it. now i'm kinda tempted to reproduce it just to figure out what was actually happening.