Legacy Code Spaghetti Navigation

Today I had the joy of finding any instance of the variable "timeout" set as a query param. This variable was controlling the timeout of the user session. The application is built in .NET, and the variable was originally set in a user control. For those of you who do not follow so far, basically a user control is a re-usable component. The particular user control I was looking at is used in the master page. Basically all of the pages inherit from the master page or some derivation of the master page. Now, on to the actual task, see where the timeout query parameter was actually being used.

This provided a good lesson, the query params could be sent from pretty much anything redirecting or loading a page. This is definitely not a reasonable approach for changing something as important as the session timeout of a user. Ideally the code should only be in one place, preferably by the backend, and if you need to override the timeout please don't override it in javascript on the client side. You can pass a query parameter in many different ways with this setup: the original page; the inheriting pages; url construction; link redirection; the list goes on... Some of the more interesting edge cases included ridiculous stuff like, if the person doing the implementation split the word "timeout" so it was a concatenation. I don't know why anyone would do such a thing, but it's certainly possible to have something like this:

"?tim" + "eout=" + timeToExpire;

Once the wheels get turning, you can think about even more edge cases, what if they were using ascii or hex, etc. It's crazy to think about how many ways you would be able to alter this query parameter with such a generic name. This is another lesson to take away from this situation. If you for some reason NEED to do this and cannot find any other way (there are a lot more ways), then the least you could do would be to name it something a bit less generic. Something I thought of which is less generic and a bit more descriptive was "userSessionTimeoutMs". Naming variables is hard, but with practice it does get easier. It definitely helps to have descriptively named variables when refactoring things over so many files like this.

Initially I thought about if it was even worth it to even start down the path of finding the references at all, should I even continue? Inevitably I did spend about 15 minutes or so looking into this problem. I spent most of the time determining the scale of the problem, finding all of the usages of the javascript function, there was only 1, and there was only 1 place that the js file was imported, it was on the user control. This is when things got a little blown out of proportion. I found where the user control was used, just 1, only on... wait for it... the MASTER PAGE! Then I realized the scale of it all and pretty much and after meticulously searching through hundreds of references I realized I had 6456 occurrences to go through. I realized that the initial problem was not really worth my time to continue searching through the rest of the spaghetti to find all of the references of timeout.

This provides another lesson for some of the newer developers which I tend to see quite a lot. Sometimes you can save a bunch of time upfront by just determining if the work is actually worth doing. If the reason for starting the massive undertaking is actually required or not. If you can recognize that there's a better solution than refactoring the warehouse full of spaghetti then you probably should take that battle and fight for that approach. It's worth at least talking to the other engineers and project managers about before you spend several weeks on something. Don't be scared to say no and offer up different solutions. You don't always have to do what they tell you, it should be a discussion.