Geeks With Blogs
Code.Blog Code Talk for the Game Developer

Recently I pulled a very bad mistake while programming/testing.  Here's the description, maybe you'll learn a thing or two.

While at work, I created an automated process that would be started when a button on a form is clicked and would then run to dynamically generate numerous text files, build an Excel file from the data in several pre-made text files, and compare that data to database values which would then populate the database.  I built the programming and got it running a few times to put the correct data in the database.  The program went to test where people were testing it so I couldn't very well be constantly continuing to change values.  I updated the program one final time and ran it against my local database (realize there are 3 databases, Local, Test, Production) and the program failed.  I figured it was just some accidental runtime exception due to a previously unclosed Excel or text file and closed the program.  Mistake 1:  Don't leave a program broken if you intend to come back to it.  Always leave code, at the least, runnable if possible.

I came back to it recently (a few weeks after initially stopping work on it) because the system is being moved to production.  I ran the program locally and the error reappeared.  I worked on it until the program ran clean, did a very very quick check of the data to make sure it wasn't Null and ran it in Test.  I only then noticed (after Test had been filled with data) that ALL of the ID's I was populating were auto-generated (I auto-generate ID's for a very small percentage of people without an ID).  I went to my Local and checked, yup, all auto-generated.  Mistake 2:  Make sure you thoroughly check your Local/Test data before moving it where others will use it.

I set all the ID's locally to NULL and rerun the program over and over, no change, all NULL.  What was going on?  What code did I have put in last that broke my program?  Mistake 3:  Keep a change log of your code if it is a program that could possibly mess with data or, at the very least, comment in what changes were made and when they were made.  In this case, I wasn't using a source control server so I wasn't able to rollback my code.

Turns out, I was in such a panic/rush that tomorrow would come and my program wouldn't run correctly, that I hadn't changed the Web.config to point back to Local from Test, I was constantly updating incorrect data in a usable Test database!  Mistake 4:  Don't panic.  When you panic, you make mistakes.

I spoke to my boss, and it turned out I had one more day (today) to fix the program.  I come in this morning, and run the program again (without changes) on my Local, and the program works just as I had always tested it.  No one changed any of the code, something on my machine must have shut down or restarted that made the data come out correctly.  In any case, it was a series of mistakes I could kick myself for.

Posted on Tuesday, August 12, 2008 8:51 AM | Back to top


Comments on this post: Practices in Poor Programming

# re: Practices in Poor Programming
Requesting Gravatar...
You had me at not using source control.
Left by God on Nov 09, 2010 10:33 AM

Your comment:
 (will show your gravatar)


Copyright © Matthew Christian | Powered by: GeeksWithBlogs.net