I once fixed a bug like that, then went wait a minute. Sure enough source control revealed I'd made exactly the same fix 2 years ago, and 2 years before that someone else had done exactly the same. In the odd years someone else undid that fix to fix a different bug that seemed unrelated. Once I figured out what the other problem was I was able to find the more complex fix for both situations.
I wished I had heard of automated tests then
Re:Is TDD Dead? (2014)
by magicalhippo on Wednesday August 26, 2020 @02:21PM
(#24285510)
Yeah I always check source control (blame/annotate), even if I wrote the code myself, just to be sure I'm not missing some context.
Automated tests is pretty great, but a lot of the stuff we do is difficult to test, mostly due to a lot of legacy code that's not well confined. As we work on a piece of code we try to clean that part up, but it takes time.
Re:Is TDD Dead? (2014)
by smileypete on Saturday August 29, 2020 @03:30AM
(#24314391)
Maybe add a dated note as a code comment breifly describing the reason for the change.
So make a patch, make a new build, send to customer and get a call "yeah that fixed it, thanks!".
Sometimes the issue is I simply don't have time to reproduce it, like that time a blocking bug had to be fixed within 30 minutes, or the customer would have had to charter their own helicopter to get a few packages to an offshore oil platform, rather than piggy-back on the worker transport heli.
Other times it's some combination of the customers system it's running on and configuration of our software that I can't reproduce.
Not saying it's ideal, but it's quite possible to successfully fix issues without being able to reproduce and test.