This is really not how I pictured by first post to go.
I really wanted to start with something about my life in IT until now and my current desire to learn more and more about coding and development and ride that into the sunset of my life.
Instead, its going to be how the interaction I had this this past Saturday went.
This interaction was between me and a Professional .NET Developer at my company when his code would not work.
What makes me so special? I just said I am learning coding. Obviously he would not come to me for advise or direction.
I am special though, because I am Infrastructure Support. Specifically, Tier 3 Windows Server support. (I know, I know. I'll sign autographs later.)
The Problem:
Mr. Developer is in the process of moving his Application from an old environment to a new one. This will result in new internal URLs because "reasons". (No, I do not really know why they decided to not just point the old DNS to the new systems.) His solution was to drop a new index.aspx file into his APP folder that was really just HTML, that showed the new link to anyone coming into the page.
Seems pretty simple, right? I worked fine at the Default Website level, but it was not working at the APP subsite level. So I get asked "Fred! Why is Windoes doing this!?!?"
Hitting his URL of servername/APP/index.aspx shows me a pretty unique error. Not a normal HTTP type of error. It shows me a .NET error specific to his APP not being able to connect to it's database.
I try to explain to Mr. Dev that this is not a "Windoes" problem. This is a "your app is broke AF" problem. He continues to disagree with me. "This should work! It's just HTML and no DB hooks!"
He is obviously under pressure. It's a weekend. This is the end phase of the migration window. People are breathing down his neck and he needs help.
Unfortunately, he is not taking a moment to think about the issue. To review the data. To understand what kind of help he needs.
A DBA joins the call. The DBA mentions that the old DB is in Read-Only mode. This makes sense, even the back-end is getting upgraded. The DB will be put in RO mode so that it can be migrated to the new servers while maintaining parity of data. He also mentions that the DB is in Single-User mode. (DING! DING! DING!)
Another Dev who has joined, asks the DBA to keep the DB RO, but to remove the Single-User restriction.
Dev 1, hears all of this, but does not feel this will help the issue. He dismisses it and drive on that IIS is failing. I get where that is coming from though. Even something as simple as an HTTP redirect will fail, if it is set up on a broken .NET app. He continues to devolve, wildly jumping from www server to www server, trying to find some magic key to work around this issue. Maybe the F5 can be configured to to the redirect? (No, no it can't. At least not in the time frame you are looking for.)
At this point, there are approximately 20 people on this call. Managers. Stakeholders. More Devs. Multiple support teams.
During one of the multitude of problem/resolution attempt rehashes, not 1, but 2 senior (I am assuming they are senior?) Devs explain to Dev 1 exactly what I was pointing out to him. "Broken Apps will not serve pages. Period."
A voice is trying to cut through the din, it's the DBA. "Try it again!"
I do an IIS reset to allow the App to restart and reestablish its DB connection and voila! The page is being served!
All good right? Of course not. Dev 1 continued to run down multiple other rabbit holes until enough validations were completed that the issue could be closed. When it was all done, we were almost 3 hours into this call. Thankfully, I'm salary! #sarcasm
What's the moral of this story? Well, beyond the fact that I need to learn Mardkdown formatting, the moral is to not panic when you have a problem. Dev 1 panicked. He did not understand why things were not working the way he expected them to. No, the way he WANTED them to. He ignored an error message that clearly and cleanly explained the problem. He ignored it after seeing it himself and ignored it when others pointed it out.
Are error messages always the be-all and end-all answer? Of course not. They should never be ignored though just because they don't fit your narrative.
Troubleshooting is an art. I've been doing it for 25 years. It's always the same process no matter what you are trying to work out. A script flow, an application function, directory services replication, or an app failing to talk to it's back-end. If you try to jump past the obvious because it's obvious. You are setting yourself up for a really day day.
Thanks for putting up with my story. I hope to make my next post a bit more relevant to the Dev.to community.
"insert catchy tagline here"
Top comments (0)