5 Reasons Why It's Not the Code, It's the Environment
Sometimes your code isn't the problem, it's the environment surrounding it. In today's post, we examine 5 reasons how your code could be compromised by environment issues.
When we first start out as a novice developers, we make all kinds of mistakes in code.
That's normal. We ALL do. That's how you learn.
As your days of coding turn into weeks, months, then years, you build a confidence (confidence, not cockiness) around writing code throughout your career. You know what works, you've either built it before or have a clear path on how to write it, and you draw upon that knowledge and experience to provide the best software available.
Then we get hired by a company where your primary job is building software whether it's web-related, mobile, or fat-client.
However, sometimes confidence doesn't fix everything. You could be the best programming out there, but you can't solve every single problem through code.
For example, let's play out a scenario:
You just deployed your code which added a new module to a multi-tier architectural behemoth. The code you wrote contains implementation, logging, and unit-tested code. It even went through a number of hours of integration testing. Everything works great and then you deploy it to production. All of the sudden...
...the system stops working.
We've all been there. After reading this, did your blood pressure/stress level go up just a bit?
As a developer, what's the first thing that goes through your mind?
Let me give you a hint:
"OMG, Did my code bring down the system?"
"Did I forget to update to the latest package/library?"
"Agghhhh!!!!...Rollback or fail forward?"
All of these ideas start flooding your mind. Throw in a dash of Imposter Syndrome and you turn into a raving lunatic ("I'm responsible for crashing the system!").
Take a deep breath and take a step back.
Creating a Rabbit Hole That Doesn't Exist
There is always the possibility the error could be something in your code. This is a great place to start.
However, there are times when it's not your code.
Essentially, you don't want to scrounge through your code unless you are 100% sure. If you are not 100% sure it was your code, don't say it was your code and start ripping it apart.
You may be creating a rabbit hole that doesn't exist.
Quit digging in the code to find the issue.
I've seen a number of developers spend hours trying to fix something when there was nothing to fix. The code was solid.
When your code is working and you haven't touched the code in X Days/Weeks/Months to cause an issue, it may be the environment surrounding the code.
Trust the code you wrote.
Checklist: Environment Issues Affecting Code
Here are some scenarios I've experienced throughout my career when the environment has caused the problem.
1. Network is down (or worse)
This is a common one.
At one company, a developer experienced a drop in network connectivity while writing code. All of the sudden, their code wasn't working when trying to access the database.
There were three developers in the cube trying to figure out what the problem was with the code. Everything looked fine.
Then one person decided to look under the desk to examine the situation further.
He came back up and said "I think I know what the problem is" and held up a disconnected Ethernet cable.
It wasn't the code.
Sidenote: This particular issue may be an opportunity to write exception handling routines for your application. What better time to test your code when the network goes down?
2. Maintenance is being done.
In big companies, sometimes there are procedures done throughout the day which interfere with programmers writing code.
For example, I was writing code at a company and experienced a "code frenzy" where the vision and path I had in my head was clear. I couldn't type fast enough. I ran the code around 3:30p to confirm it was functional. Success!
I started refactoring the code to make it more efficient. 45 minutes later, I finished and ran the code.
Errors started appearing.
After looking it over for 15 minutes, I couldn't figure out what the issue was with my refactoring.
I reverted the code back to the functional state when it DID work before the refactoring.
Errors still appeared.
I needed a second pair of eyes and asked one of the employees of the company why this code wasn't working.
He said "it's probably because the database and servers back up at 4:00p every day and they aren't available during this time."
I checked the clock: 4:30p.
Uh-huh. I left for the day.
3. Insufficient Storage Space
This was also a funny one, but keep in mind, if you work in a corporate environment and you have regular arguments about justifying storage space for a revenue-generating website, it may be time to start job-hunting.
I can't remember who said it way back when, but the one philosophy I've adopted throughout my career has been "You can never have too much memory or storage."
One company I worked for didn't share this same philosophy.
One day, we published the website to a company server and noticed there were issues trying to bring up the site. It kept saying the application wasn't there and was causing errors.
Once we dug into the issue, we found out a number of files, including the web.config, weren't copying over to the server which made the web application DOA.
Finally, we decided to check the server's hard drive.
It had 1K of storage left.
System Administrators decided to steal from Peter to pay Paul: Move files around and clean up hard drives to get more space. Honestly, it would've been easier to buy additional storage.
Again, it wasn't the code, it was the environment.
4. Missed requirement
This is a rare one, but it's happened twice in my 30 years as a developer.
The developer read over the requirements, started to write code, and finished it off with unit tests. Developer peers confirmed the requirement and conducted the code review. They handed it off to QA. QA read the requirement. They confirmed it. They gave the go-ahead and sent it over to the deployment team.
The good news was it was successfully deployed and put into production.
The bad news was there was a requirement missed.
Yes, a requirement was missed because of an attachment got lost in the digital shuffle and wasn't opened or included in the primary requirements.
What's worse was the number of people who confirmed the requirement and knew this was the way it was supposed to work. So it went through at least 5 sets of eyeballs and approved for deployment by each one.
Oh well, throw the requirement on the backlog for next sprint. ;-)
5. Server isn't available/up
While we could consider this a "Network is down" issue, I feel it's more of a "server wasn't on the network" issue.
Web APIs always require a destination server. If everything in your code is working and you make a call to a server, whether it's an app server or database, internal or external, and it isn't available, there's an environment issue.
Granted, your code should handle successful request scenarios as well as error-prone scenarios, but if it can't hit a server on the network, you may need to investigate why the server isn't up.
Exception-handling is crucial to avoid these kind of issues. Again, this may be an opportunity to write better code since the server isn't up.
Conclusion
As you can see, I've experienced these types of situations and they've occurred between 5-10% of the time where it's the environment causing the issue and not the code itself.
As always, hindsight is 20/20 and developers conduct the deep sigh of relief when they realize it wasn't their code.
Somehow I feel like Mr. Spock's (and Sherlock Holmes?) quote fits for these types of scenarios:
"When you eliminate the impossible, whatever remains, however improbable, must be the truth."
Expand your sight past your code and be aware of all the components involved at play here besides just your code: Be able to view the forest through your coding "trees" and determine what elements surround your code which could cause issues.
Have faith in your coding skills, but be aware of other environment issues. You can only code for so much.
Did I miss an environment issue? Have you ever experienced any of these problems? Post your comments and let's hear your story.