I've recently been developing an application at school which pulls class data out of our management system and spits out an editable seating plan. It's meant to be an easy to use, press one button and don't worry about it job.
After a few evenings of programming I had something that worked fairly well and got to the point where I needed to test it with some different data sets to make sure it didn't throw its toys out of the pram when presented with unexpected information.
I got to a point where I thought it was pretty much finished and off I went down to the technicians office to share what I'd been doing and get them to test it out for me. So, there I was, clicking away, showing how you could go back, change your mind, change options, load a different data file and so on and it was all working as it should.
No. I lie. As is so typical in computing, what works perfectly for you every single time will inevitably die in a hideous fashion as soon as you present it to anyone. Its like oranges and bananas in your fruit bowl - they're fine until you walk out of the room, at which point they immediately go soft, brown or gooey.
I fired it up, loaded the data file and showed how it works. At which point I changed one of the options and suddenly all the data disappeared. I then uttered the words that all people who work in IT say when they have absolutely no idea what's going on - "that's interesting" which translated means, "I've broken it and have no idea how, why or what I'm going to do about it."
If you were in my class I'd now suggest that you bung a break point in the program at a sensible point and then step through using the debugger to find out what's going on. So, once I'd got to the point where I could replicate the error every single time, this is exactly what I did, and this is where it gets weird.
You can switch off now if you're not interested in the beardy bits...
The data in my program is stored as a list of objects, which when a button is pressed is then passed to another form which then rearranges the data into the order the user selects and then fills the form in the layout requested. None of the code is destructive and once the form is closed, the data is re-sent from the main form if another plan is required.
What was happening was at some point the list of objects was being cleared - which should be fairly easy to pin down. So I started following the program and watching the contents of the list at each stage.
The code would run first time without any issues whatsoever, but click the button a second time and this time when a certain sub routine returned, the list would be empty. The strange thing was that at the end of the sub the list was populated, but on returning was cleared.
"it's a byref, byval problem!" I can hear you say. "Think about the scope!"
I'd agree with you, but if that were the case the list would be cleared every time. Nothing had changed, the exact same code was being run. First time, fine. Second time, not fine.
Scratching around for a solution I then commented out one line of code. This line was before the list was finally populated at the end of the sub routine and the debugger had shown worked fine.
It worked. No bug any more.
This was mind bending for so many reasons - the line didn't empty the list on the first run through, didn't empty the list when debugged and wasn't the point at which the list was disappearing in the debugger - this was happening 3 or 4 statements later! But yet... it fixed the problem.
This happens in programming sometimes. You can do something that absolutely shouldn't work or shouldn't have any effect on anything and yet you'll get bizarre results. I'm still lost as to why this fix worked, but considering my code isn't going to risk anyone's life, I think I'll take it and walk away...!
Inevitably, this can happen in class as well - try explaining that one to 25 perplexed students...