Abort, Retry, Fail
-
5'd to compensate for the 1-voting tool.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997It's sad that people 1-vote when a question is asked. Are we all human? Do we make mistakes? Heaven forbid we actually, gasp!, admit them to others!
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
I fixed today a bug, where I accidently locked out regular users from an application. Only administrators where allowed. The customer recently began to set up user accounts for the staff - none of the accounts worked :rolleyes: I changed a code row while refactoring from
if(xx!=-1)toif (xx>0)and it should have been at leastif(xx>=0)(all java). regards TorstenI never finish anyth...
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
At a previous company someone managed to put to live some code with a debug message in it so that whenever a user did a particular task in one of the screens (busy users could do this a hundred times a day) it popped up a messaged saying "Hello" with an OK button.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
5'd to compensate for the 1-voting tool.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Someone with a reasonably large rep is 1'ing.
Panic, Chaos, Destruction. My work here is done. or "Drink. Get drunk. Fall over." - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre Have a bit more patience with newbies. Of course some of them act dumb -- they're often *students*, for heaven's sake. -- (Terry Pratchett, alt.fan.pratchett)
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Once deployed a system with a debug screen that displayed the stored data prior to a save, this wasnt pointed out until a good year later, I removed the code in the following release, next think we knew the business raise a critical fault log because this debug screen was not appearing and was vital to the business process!
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Not my most recent, but... A customer took some new EPROMs I sent him from his London office, to a Glasgow Telephone exchange for live testing. When he got there, he tried them, and couldn't find any of the new code functionality. He calls. I assume he has the previous version, so I blow some more latest version, while he flys down to Hampshire to get them. He dives in, collects the proms, and dives back to the airport (he had an "appointment" with one of his girlfriends in Glasgow that night). A few hours later he is back on the phone - same thing. Who hadn't taken the "if development machine" code check out of the production code? Oops. :-O
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Manfred R. Bihy: "Looks as if OP is learning resistant."
-
Someone with a reasonably large rep is 1'ing.
Panic, Chaos, Destruction. My work here is done. or "Drink. Get drunk. Fall over." - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre Have a bit more patience with newbies. Of course some of them act dumb -- they're often *students*, for heaven's sake. -- (Terry Pratchett, alt.fan.pratchett)
Yeah - I'm seeing a rash of -16's and -8's in my rep history. I remember someone saying once that people with a reasonably huigh rep wouldn't do such things, but I guess we've proven them wrong today.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
5'd to compensate for the 1-voting tool.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997John Simmons / outlaw programmer wrote:
the 1-voting t fool.
FTFY
-
John Simmons / outlaw programmer wrote:
the 1-voting t fool.
FTFY
Actually, "tool" is a slang reference to the male reproductive organ, and thus, way more appropriate.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
John Simmons / outlaw programmer wrote:
the 1-voting t fool.
FTFY
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Not most recent - but a fun one nonetheless. Chap was tasked with changing the Invoice print to ask for a number of copies to be printed - simple task, knocked it over in an hour, tested, and distributed by the ned of the week. One Happy Customer. Until a week later. After refilling the printer with (from memory) four boxes of paper, it was still printing invoices. when they (finally!) checked, they noticed the same invoice was printing over and over again... "Imposiible!" quoth the programmer responsible for the change. Look...
Do
PrintInvoice();
CopyCount--;
Until CopyCount == 0;Turns out the user had decided she didn't actually want to print the invoices at all - so entered zero for the number of copies!
MVVM# - See how I did MVVM my way ___________________________________________ .\\axxx (That's an 'M')
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Tim Carmichael wrote:
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system.
:wtf: :wtf:
That's called seagull management (or sometimes pigeon management)... Fly in, flap your arms and squawk a lot, crap all over everything and fly out again... by _Damian S_
-
Not most recent - but a fun one nonetheless. Chap was tasked with changing the Invoice print to ask for a number of copies to be printed - simple task, knocked it over in an hour, tested, and distributed by the ned of the week. One Happy Customer. Until a week later. After refilling the printer with (from memory) four boxes of paper, it was still printing invoices. when they (finally!) checked, they noticed the same invoice was printing over and over again... "Imposiible!" quoth the programmer responsible for the change. Look...
Do
PrintInvoice();
CopyCount--;
Until CopyCount == 0;Turns out the user had decided she didn't actually want to print the invoices at all - so entered zero for the number of copies!
MVVM# - See how I did MVVM my way ___________________________________________ .\\axxx (That's an 'M')
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
I used System.Security.Permissions.FileIOPermission in C# so I could check for file permission only to discover that Window 7 will still throw exceptions otherwise. Oh, wait, that is a rant.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
-
Tim Carmichael wrote:
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system.
:wtf: :wtf:
That's called seagull management (or sometimes pigeon management)... Fly in, flap your arms and squawk a lot, crap all over everything and fly out again... by _Damian S_
The developer that wrote the application used the web service provided by corporate. I don't blame him - he did what he was told. All was fine and good until corporate decided they wanted to make changes on the development server, then the problem came to light.
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
I rediscovered that dereferencing
NULLis bad karma.Software Zen:
delete this; -
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Actually had a similar SNAFU today. We are a Canadian retail giant (if you're Canadian, you can probably figure out who!) and last night we deployed a new version of one of our major applications that has hundreds of users within the company and across the country. However, the install package was created with the wrong security INI file. Instead of pointing to our Production security server, it was pointing to the Development server. :omg: Obviously 90% of our users are NOT configured on the Development server, so hilarity (read: CHAOS!) ensued. Unfortunately, since I'm currently the only developer with access to create the correct install package, the problem wasn't solved until around 9:45 after I got to work. The package needed to be distributed to local SMS servers country-wide by another department, so another hour or so was required until we could provide a new install package to the users. All in all, users were deprived of that application from the opening of the availability window at 7AM until around 11AM. Gonna look really good on our system statistics next week. :(( Needless to say, my manager was not amused. -EM
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Hmm, I just thought of another one involving me ...... maybe I'm not actually cut out for this job???? :laugh: In my first job I was working on an ERP system called Triton (anyone else know it? it later became known as BAAN), and we needed to correct a label printing issue for one of our clients, a furniture manufacturer. We needed to test on the specific printer at the client site to make sure the spacing requirements were met, so we were told to substitute one of the text fields on the label with my name and the users would know that it was us and to notify how it went. Well, after we put the correction in production my buddy, a Consultant at the client, came by and told me that we'd forgotten to remove my name from the code and that quite a few shipments had gone out with the my name on the shipping labels, and some of the client's customers were inquiring as to who this "EM" guy was! :-O My buddy still gives me grief over that one! -EM
-
Not most recent - but a fun one nonetheless. Chap was tasked with changing the Invoice print to ask for a number of copies to be printed - simple task, knocked it over in an hour, tested, and distributed by the ned of the week. One Happy Customer. Until a week later. After refilling the printer with (from memory) four boxes of paper, it was still printing invoices. when they (finally!) checked, they noticed the same invoice was printing over and over again... "Imposiible!" quoth the programmer responsible for the change. Look...
Do
PrintInvoice();
CopyCount--;
Until CopyCount == 0;Turns out the user had decided she didn't actually want to print the invoices at all - so entered zero for the number of copies!
MVVM# - See how I did MVVM my way ___________________________________________ .\\axxx (That's an 'M')
