Perfect, now you just have to wrap your program inside a debugger in production!
We test AND develop in production. Get on my level.
One of our customers does that. It happened multiple times already that one dev fixed an issue in production, and the next regular deployment overwrote everything.
But fortunately, it’s just critical infrastructure and nothing important.
When I left my last job they were using the zip file method for version control and one creative developer managed to link two versions of libc at the same time.
Software is so useful that the standard for utility is extremely low.
Clearly you should just ship it with the debugger and call it a day
Exactly, who would put a rebugged version into production anyway?
That would just be irresponsible we want fewer bugs not more of them!
For those of you who’ve never experienced the joy of PowerBuilder, this could often happen in their IDE due to debug mode actually altering the state of some variables.
More specifically, if you watched a variable or property then it would be initialised to a default value by the debugger if it didn’t already exist, so any errors that were happening due to null values/references would just magically stop.
Another fun one that made debugging difficult, “local” scoping is shared between multiple instances of the same event. So if you had, say, a mouse move event that fired ten times as the cursor transited a row and in that event you set something like
integer li_current_x = xposthe most recent assignment would quash the value ofli_current_xin every instance of that event that was currently executing.When I write APIs I like to set endpoints to return all status codes this way no matter what you’re doing you can always be confident you’re getting the expected status code.
Someone has a compiler if statement left somewhere in their code (… probably)
The most cryptic status code I’ve received is 403: OK, while the entire app fails to load
