Like any typical Thursday, I was sitting in my Web Science Systems Development lab session. While gleefully attempting to work on the lab assignment for the week, I picked up on a couple students sitting at another table, talking about their favorite technologies, tools, services, methods, and comparing each other’s development preferences. As the two hour lab went on, each got more and more frustrated with the other, throwing retorts that included phrases like, “Oh yeah? Well, my favorite tool is [x]. It’s waaaay better than what you’re doing;” “You should use [some experimental technology y] and [complete some crazy, convoluted process in order to make it compatible with mainstream services];” and—my personal favorite—“Wow, you’re still doing that? That hasn’t been cool since, like, 2014.” It was quite entertaining, to say the least.
As a side note, The Poly’s Photography Editor, Sidney Kochman, requested that I use this notebook as an opportunity to attack JavaScript and “that crazy ecosystem.” Sorry, Sid. Not today.
Although it was pretty fun to listen to, as the lab hours went on, I started to think about the basis of the conversation. Computer science and information technology are fields that are notorious for having ten different ways to accomplish a task. This is by no means bad, but it leaves a lot of room for differing opinions and preferences. Sometimes, there is an ideal way to complete the task at hand, but not always.
Take web development as an example. Say you are interested in building a simple web application. For server-side code, you have a couple options: Node.js, Ruby on Rails, and PHP, to name a few. For databases, you have the chance to make the choice between a wide variety of technologies, including PostgreSQL, MySQL, MariaDB, MongoDB, and Microsoft SQL Server. Now that I have bored those with no interest in the nitty-gritty, you can see that there are quite a few options for each step of the process, each with their own set of pros and cons.
Provided that different options can sufficiently and feasibly complete the task at hand, differences in personal preferences and choices in technology are okay. As long as a developer is willing to document code and decisions for others to understand in the future and can complete the task at hand, I see no problem with the choices made.
Furthermore, as exciting as new and groundbreaking technologies may be, the industry standards often do not move fast enough to introduce these new technologies while they are still considered groundbreaking. Perhaps that is the reason they are groundbreaking: the industry standard is the ground to be broken.
Take Ruby on Rails for example. The web framework was greeted with excitement and support, similar to what Node has received in the past two years. But, even as its tenth anniversary approaches, Rails still has not overtaken PHP as the leading web technology, and Node is eating away at its market share.
This is the gamble that using the latest technology brings: you do not know if the technology will become widely used as time passes, let alone if it will mature or be abandoned. This gamble is what keeps some technology firms from quickly adopting these new technologies.
So, the next time you see someone using PHP to build a web app or C to build a program that could be painlessly built in Python, please remember this editorial. Firstly, he or she has every right to; that is the person’s prerogative. Secondly, it may be good experience for future jobs or responsibilities. The converse is also true, however. If someone wants to use ECMAScript 6 instead of the approved JavaScript standard, that is alright as well, as long as the person is willing to document the code and explain what may be unclear.