Aug 17, 2018

|

by: james

|

Tags: Best Practices, Developers, Tips

|

Categories: Tech Tips

The Rain in Spain

The Rain in Spain

A problem that I’ve noticed with us developers is that sometimes we hear some techie and cool sounding trivia – you know, like “the rain in Spain stays mainly in the plain,” take it as fact, and integrate that fact into our daily dev lives.

I’ve reviewed code where every instance of an if/else was replaced with the ternary operator.  When I asked the developer why he chose to do that, he said it was faster – that a former lead dev of his once told him to do something similar for “performance reasons”.  Well, I don’t suspect the ternary operator is any faster, and even if it were, the minimal performance boost that might have provided in this case could have easily been classified a rounding error based on the performance of the rest of his application, which was I/O bound as it was laden with several network and database operations.

Other times I’ve been told, “make sure all your SELECTs have NOLOCK hints on them, it’s faster,” or, “wrap each of your methods with a try/catch to make debugging easier”.  Uh, no!

We all fall victim to this type of thing at one time or another.  To this day, I still prefer the pre-increment and decrement operators over their respective post operators because they are faster – or so someone who I respect once told me.  That one at least turned out to be true, but, again, I bet there are some tweaks that I could make that would be orders of magnitude better from a performance standpoint.

Of course, most of the time, these things started with good intention to solve a very specific problem.  Replace an if/else with a ternary operator?  Maybe the developer thought it would read better and be more maintainable.  NOLOCK on a query?  Maybe in some export process which the data is understood to be ever changing.  The try/catch?  Perhaps it was to catch a very specific condition and take action on it (or maybe the person that told you that one just didn’t know how to read a stack trace).  In any case, there was some origin to these – a raison d’être – a reason that they exist and a scope in which they should be applied but seldom all the time.

In all of these cases and many more, even though there are different rationales behind them (performance, debugging, etc.), there exists a single commonality between them: it was some trivia, standard, or some such that was decreed from up high to a more novice developer who took it as doctrine and now get to be passed on again and again.

Regarding the rain in Spain?  Well, it falls mainly in the mountains, actually.