A Silly Mistake Can Lead to a Big Mistake

Writing code and testing software are both challenging tasks in Software Development. It is never easy to make cent percent synchronization between these two. It is challenging for a developer to write almost flaw less code similarly it is challenging for a tester to cover almost cent percent of testing path.

Very often we are in a situation where we are forced to or we have to overlook some minor analyses and we leave some very minor flaws in code or in testing.  Because of the ignorance of the analysis apparently we think that those minor flaws won’t affect the whole system in its major functionalities. But in reality a very minor flaw in the system can lead it be an unusable system.

Few days back I was asked to develop a tool to modify an SQL file which were generated form a replicated database and had to execute the modified SQLs to a pgSQL database. The original file size was 70-80MB and total number of lines were about 600K.

The main task was to filter out some specific SQL blocks from the file then writing those modifications into two set of files. One set of files was a single file that contained the whole modified SQLs and another set of files was with multiple files that contained the modified SQLs as several chunks.

Since number of lines were huge so it was difficult for me to test all those line manually, but I tried my level best and found it to be according to the requirement. I opened those files manually and seemed to be OK. I executed the second set of files (the chunk SQL blocks) and these were successfully executed to the desired database. BUT when I executed the first set which contained the whole modified SQLs then it showed me syntax error.

I started to analyze the file and found that very few of the very last lines were not present in it. It was also very interesting that the skipped lines were started from a middle of a line, I was sure about my logic that either it will write a complete line or skip it completely, fraction of line is impossible.

So at first glance I supposed it to be a memory related problem and started to minimize the original file size but found the same problem every time  I minimized the files. That really shocked me as the other chunk files even bigger than my problematic was OK. Then I went to the source code and found that every StreamReader or StreamWriter I used for reading/writing files were properly closed except the problematic one. I modified the source code and then executed the tool which then solved the problem.

As we know an opened stream made a file inaccessible but in my case I was able to use it and that made me think that closing the stream wasn’t big a issue apparently.  But that silly mistake made my application a useless one. That is why every developer and tester should be aware about his silly mistake, they need to increase their analysis even after a very very minor case, they have to increase their foreseeable power.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s