[JohnR]

Here's a question for you: you've made some changes, and in testing you execute something that you know is not going to work. But it works anyway.

Should you be pleased, or very unhappy?

[JfTM]

Isn't that a feature?

 

[BobRex]

I wouldn't be happy.  You know full well that if you can get the wrong result, some other bozo will too and cause you no end of grief later.  Best to track it down now.

[JohnR]

Well, it's the right result, but not for the reasons that you think it would be

[xr2]

Depends.  If it means that you're test environment is in better shape than you thought, then it's a good thing.  If it is really supposed to break, then you have one of the more annoying type of bugs to track down.

[mgalusha]

It would bug the hell out of me until I could get it sorted. The ones that really concern me are big changes to something and having it work the first time without any errors. Had this happen yesterday, split a class into three files using "partial class" declarations in C# and the damn thing still worked afterwards. Worried me as I expected something bad to happen but we beat on it all day today without issue.

[Chromisdesigns]

I used to encourage my coders to include some tell-tale in test versions so they were sure they were executing the version they thought they were -- sometimes this result can be as easy as compiling into the wrong library, wrong lib references, etc., etc.  Of course the sandbox may not be configured the way you think it is, either.

We always used a global switch to turn off all the coding aids and debugs when it was declared production ready.

[chester_audio]

Hard to say what level of concern this is without some more input. What do your specs call for? If it violates a spec, it's a bug. If it doesn't, and there seems to be a problem, then the specs need to be revisited. Perhaps something needs to be added to the design to prevent that particular senario. I would have to know exactly what was going on, and my bosses would expect me to know.

[JohnR]

Well, let's not over-analyze my question I guess you could think of it as an "inverse bug" - as Mike says, rather an uncomfortable feeling, more than a regular bug.

[chester_audio]

Sorry. I'm a software engineer, it's my job to over-analyze. 

[MaxCast]

I say, if you're getting paid for the coding...find out why.  If not getting paid...let er rip.

[macrojack]

This whole discussion must be in a code of some kind. No idea what the problem is.

[kimchee411]

No.  If you don't understand what is going on and you push it out to production, it could very well come back to bite you in the ass and you won't know how to fix it.

[Crimson]

Here's a question for you: you've made some changes, and in testing you execute something that you know is not going to work. But it works anyway.

Should you be pleased, or very unhappy?

Mildly pleased.

And then I would find out why.

[wilsynet]

The idea of "you know it's not going to work" can be interpreted a couple of different ways.

1. You made significant changes and no way could you be so good that it worked on the first try.  This is not a big deal.

2. According to the analysis done, the compilation or execution of the code should fail either syntactically or semantically for one or more known and well understood reasons.  If this is the case, then either the code is doing something that was not intentioned, or your analysis and the foundation that informs that analysis is wrong.  This needs to be rigorously understood because either:

• There's a bug and you're just lucky that you haven't hit it yet.  The code may be doing bad things that you haven't observed but it's doing so all the same.
• You don't understand the nuances of your creation.  Good to know, but not the end of the world I suppose.
• You don't understand some aspect of the programming language or platform.  Resolving this would benefit you in the long run.
  

My general thought is that rigor is rarely a bad thing, although of course there are time, cost and delivery constraints which may cause you to compromise in one way or another in the interests of pragmatism.

[mal]

Here's a question for you: you've made some changes, and in testing you execute something that you know is not going to work. But it works anyway.

If you don't know why it works, it doesn't work. Anything else will drive you mad until it bites you in the fleshiest part of your...

There's no sense in feeling pleased or unhappy. It's just a funny step on the way to being done.

[JohnR]

OK, thanks for responses folks It wasn't supposed to be an exam, just a mildly amusing topic to elicit your experiences...