It’s not my fault, it’s the library!

January 11, 2008

Before you say that, think carefully. Years before, I’ve been into this large project. I think we have like ten projects running simultenuously with hundreds (if it was not a thousand) of people in the factory. They’d have like software engineers, programmers, hardwares people, managers, even the top executives running on site. So, it’s pretty big. I’m in the software department, obviously, as a junior developer (they called me that eventhough I think I’m the most skilled one in my team. we’re only a team of 4). Upon entering the project, I quickly realized that we are running on a very specialized platform where facilities that we used to have were non existant. Even the debuggers need some special hardware enhancements and special softwares to run. Compiling and running the code would take you about 2 hours at minimum. So, there were lots of frustration and we have to make sure that when we write code, we wrote it right the first time, or else we’ll just wasting time. The code base were so big that it is impossible to inspect or understand all of it. Not only that, the program were written in C, but without any means of structural designs. So we have a couple of this BIG main functions that says something like:

function A (){
 while ( 1 ) {
   switch ( globalVar1 ) {
      case 1: …
              break;
      case 2: …
              break;
        …
   }
 }
}

And we got some parallelism that some functions/files/modules run on different processes. We access memory deliberately that if I missed a number, such as I write 1 instead of 2, it will crash my module completely without any noticeable faults. So, you can see that its not a pretty sight.

Along came a bug that is so frustrating and unfortunately it was assigned to me. Still quite shocked about the program structures and the scarce of utilities I tried to find the source of the bug. After a while I got so frustrated that I concluded that the fault must be in the library that our module were using. Confident with the conclusion I told my manager. This is what he says:

Manager (M): You sure of this
I: Yes
M: You have checked the codes
I: Yes
M: You tested it?
I: Of course…
M: You have proof?
I: Ummm,… well I’ve seen it running
M: You have direct proof?
I: Err,… not really
M: How can you tell that its the library fault?
I: A guess…
M: Look, we’re engineers, not economic analysts. There’s only 1 or 0, true or false. Give me some proof before you came into conclusion
I: … yes sir
M: Check it again

So I get back to my console and check the codes one again, line by line, code by code, files by files. AND there it is. A bug that I wrote (doh). So I fixed it and came back to my manager.

I: Sorry sir, I’ve found the bug and fixed it.
M: You sure?
I: Yes, I’ve tested it and I have proof
M: Good. In my experience, 99.9% of bugs came from the developer and not from the library, so don’t give me that piece of crap next time
I: … I understand. I’m sorry sir.

Lesson learned. Don’t ever make the assumption that the library at fault at first time. 99.9% of bugs came from the developer not the library. That words were deeply engraved in me even right now. Happy coding!

Advertisements

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

%d bloggers like this: