Chances are that if you’ve worked in tech long enough, you can probably rattle off a list of tech fads you were forced to suffer through. But you know what my secret is? I have yet to fall for the siren song of any tech fad. But rather than just laughing at a few older fads, I’d like to try and provide some instruction on how one can tell the difference between tech fads and legitimate tech trends.

You may be asking yourself: “What is wrong with tech fads?” Well that’s a good question. As software engineers we are generally expected to design and create tech solutions to problems which will stand the test of time. If you design a solution that is supposed to be long lasting around a tech fad, the ability of your solution to perform consistently in the future may be compromised once the fad dies. If a major portion of the tech stack your solution relies upon falls out of favor and is no longer supported, then by extension supporting your solution becomes that much more difficult. Inevitably both you and your client will be negatively impacted by this situation.

Dilbert Change Cartoon

Regarding the Dilbert comic above, the difference between a short lived tech fad and a dead woodchuck under the porch is simple. If you choose to participate in the tech fad and it rolls over, then you’ve got yourself a dead woodchuck. The most important take away here is that you always have a choice. You can choose to go with the fad and hope it turns into an actual trend or you can choose to use something else.

But still the question remains: How do you know the difference? Well as it turns out this is actually the simplest part. Simply ask yourself the following questions:

  1. Does it make sense?

    While asking this question should be exceedingly obvious, a lot of people neglect to do it. The inability to ask this question is what led to notable tech fads such as Coffee Script. Yeah it’s still a thing, but thankfully the only people stuck with it are the people who made the mistake of buying into the fad to begin with. The rest of us don’t have to care.

    Why doesn’t Coffee Script make sense? Because it affords no actual benefit to anybody who matters. It’s basically a stylistic layer of transpilation which is turned into actual javascript at some point. It doesn’t target some emerging standard or enhance backwards compatibility but rather appeals only to the aesthetic sense of a subset of software engineers.

    In addition while it doesn’t enhance anything the customer/user cares about, it actually introduces additional barriers to entry which will make it more difficult to bring other engineers into the fold. This is a real concern especially after a tech fad begins to die. This is because when it comes to tech, the more esoteric something is the more people can and will charge you to work with it.

  2. Is it relevant to the problem at hand?

    This is yet another question everybody involved with a project should be asking when it comes to any tech that is being considered for inclusion. The reality is that when it comes to the fads, engineers (sometimes as directed by their managers) tend to design solutions around the fad itself rather than the problem they are tasked with solving.

    This is exceptionally dangerous as it not only runs the risk of increasing your projects chance at experiencing premature obsolescence but likely indicates that you aren’t focused enough on solving the actual problem. This of course is a classic case of missing the point. A good present day example of this syndrome is any of the legions of projects which utilize the “Blockchain”. While the “Blockchain” is a sensible construct that solves a real problem present in the world of decentralized crypto-currency (ala Bitcoin) it makes very little sense for most other things. This counts doubly when it comes to centralized systems.

    Another great example of this syndrome is the wide proliferation of NoSQL database technology. While NoSQL databases make sense in a narrow range of use cases, the reality is that for most enterprise oriented tasks, a relational database which can be queried using SQL makes far more sense. The heart of the NoSQL trend seems to revolve around the fact that a lot of devs seem to hate dealing with SQL in general. As a fan of Dapper, I obviously don’t personally count myself as part of that group. In any event, I think its extremely dangerous to pick techs based solely upon how large the barrier to entry is.

  3. Will it still be viable in 10 years?

    This is generally the hardest question to answer. That’s because it’s kind of impossible to definitively answer this question without indulging in some supposition. The reality is that you can’t get a feel for how long something is going to last if it is brand spanking new. The best way to answer this question is to allow techs under consideration to mature a bit before you begin to build solutions around them.

In addition there are other factors to consider when choosing techs for your project. Personally as a staunch FOSS (Free and Open Source Software) advocate, I feel that building solutions around FOSS based tech fads is inherently better than building solutions around proprietary tech fads. That’s because even in the event that the fad goes belly up and the people maintaining the FOSS project in question scatter like cockroaches when the light comes on, you still have the option of maintaining that tech yourself.

Practically, that is likely not going to be an option for smaller players as some of these projects can be quite large and maintaining them in a viable manner will require a lot of resources. However there is nothing preventing you and other like minded consumers of FOSS based tech fads that have fallen by the wayside from banding together and maintaining it as a group. After all one of the most beautiful things about FOSS is how it’s able to bring people together from different disciplines and unify them with a sense of shared purpose.

Nevertheless, regardless of whether or not the tech fad in question is FOSS, my advice is that you are best off avoiding them when it comes to designing solutions. TLDR: The most effective way to do this is to ask yourself and your colleagues some simple questions as a sanity check and to make sure you stay away from anything that is too bleeding edge.