Have Confidence in Your Skills By Ruling Out External Resources

An experience like this can really shake a programmer's confidence level. Today, I share a couple of experiences that proved external resources were the cause.

A while ago, I wrote a customized dashboard for users of an ecommerce system. It was something that I was proud of it when it released to the users of the system.

Before deploying the code to a development server, I ran the dashboard on my local machine. I ran the unit tests and integration tests. I finally connected to the database to confirm everything worked.

Everything worked great.

Fifteen minutes later, I deployed my code to the dev server. Once completed, I started loading the web page to test it.

It failed. Why did it fail?

I started looking through the code to check and double-check where it was failing.

The key to this was it was connecting to the same database on my local machine as it was on the development server.

For you Microsoft devs out there, the web.config's connection string was the same. This was fine because I wanted to test against the same database.

So why wasn't it connecting to the database?

"I don't get it. Everything works fine on my machine."

Then I would hear one of my ex-bosses's voice saying:

"We're not shipping your machine to all our customers!"

What happened?

We've all been there when we've tested code.

Everything works on your machine, but when you deploy it, everything blows up and you don't know why.

Before I tell you the solution, let me explain another situation that occurred.

Two days ago, I overhead some team members trying to figure out a particular issue. The QA team submitted it as a bug.

The developer modified a piece of code and ran his unit tests and integration tests.

Integration tests were failing.

He modified 2-3 lines of code, but didn't touch a section of code where the error occurred. The developer kept saying, "How could it be breaking when I didn't touch that code?"

I mentioned to one of the devs, "if I was a betting man, I would place my money on data."

After researching the issue, it turns out the data did change. The record for this particular integration test changed. Once the data updated, everything started working again.

His code wasn't the issue, it was the environment around it.

We are taught to write code to solve solutions, but our code needs to "expect the unexpected."

The environment can change at any time and sometimes, we need to code for worst case scenarios.

Not all the time, but most of the time.

The solution?

Back to my original problem.

Why couldn't I connect to the database and it was giving me a weird error message? The database was fine and the data didn't change.

The problem was a hardware issue. The database server ran out of disk space and couldn't open the files to function.

Hence, the error.

The code was fine. The environment around the code caused issues. It wasn't code.

Conclusion

As you write and deploy code in your career, trust the code you write. Create unit tests and integration tests to validate everything happening in the system.

I'm not saying from this point on, it's everyone else's fault and not your precious code you wrote. ;-)

If your unit tests and integration tests pass and your code fails on another machine, don't rule out the external resources.

Don't immediately go to code. It may be external resources creating the errors.

Has anyone else had code "work on their machine?" Post your comments below with your experiences.