Technology Bandwagons (a.k.a. "New Idea Fatigue")

Wed 13 May 2015 by Kristofer M White

The topic came up at work today when I posted a quote in our software room in HipChat.

I also would argue that we need to recognize fashions and trends in the computing world that don't always correlate to efficiency, practicality, or necessity. If we remember the last twenty times we jumped onto a bandwagon that went nowhere, we might be more cautious next time. In short, we need to understand the past in order to cope with the present and create the future.


I was asked:

@kmwhite please list the last 20 bandwagons you jumped on that went nowhere

It was a perfectly valid response. My simple reaction was:

Every JS framework that gets replaced the next day by "New Hotness". (troll)

It elicited a laugh and people moved on. However, it wasn't an actual answer. This got me thinking.

Can I count 20 bandwagons? No, I cannot. Can I count some? Yes. Have I been burned multiple times? Yes.

Inherent Aversions

The on-and-off work I have done in operations through my career has made me more hesitant to adopt new technologies/frameworks off the bat. I have seen a lot of people do it and the results are nothing more than an overly complicated ecosystem that yielded little gain besides increased cognitive load on both Dev and Operations. While I fully believe in "using the right tool for the job", sometimes the "Right Tool™" is really the "Acceptable Tool™"1. Did cleaning up after other people make me a little curmudgeon-y? Probably. But as I find articles like "Programming is Not a Craft"2, "Choose Boring Technology"3, and "On Ruby"4, I realize I am not alone in these thoughts. I have an immediate aversion to new technology.

The major difficulty with this inherent aversion to things is that I can too quickly rule out a valid tool. Let's take the troll-y example of JS libraries I used. Where JS frameworks are an easy target, since they change every other day zombie-happy, what about Node? It was forked to IOjs. Thankfully, they have valid reasoning:

This project aims to continue development of io.js under an "open governance model" as opposed to corporate stewardship.5

This was the only reason I read that I agreed with. The migration to Semver6 also was a sane idea given the changes that went on. However, I still ask "Why are we using Javascript on the server anyway?!" Is that me being adverse to so called progress, or simply questioning the lack of learning a new language (Java? Python? Ruby? Perl? ASP? Should I keep going?) that already runs server side. Existing server-side languages and tools have had evented frameworks for a LONG time. Twisted for Python? EventMachine for Ruby? Hell, even Event for Perl! What did Node and/or IOjs really provide besides the ability to bypass learning a new language?

Now, before someone goes "But Kristofer, what about the 'adequate tool for the job'? Maybe learning something else would create additional complexity!" This is true, but aren't our languages really just tools for processing data? The operational complexity of these existing frameworks are Known Entities. Building a new toolset to port a language from a browser to a server side application is NOT a Known Entity. It's the epitome of "doing something cool" rather than "doing something pragmatic". I'd love for an opportinuty to hear the rationalization of NodeJS' inception.

Additionally, learning the language should be an expectation of an engineer in our industry. That would be like me showing up to a construction site with a hammer going "NO WORRIES. I GOT THIS." One trick ponies are unacceptable. If you're a "${LANGUAGE} Developer", you're doing it wrong. Learning the language isn't the increase in complexity, but changing the ecosystem of your infrastructure is. You should always be learning languages and paradigms7.

Technological Depressions

I wanted to say "I'm depressed about the state of industy" (I really did), but it doesn't properly express the sentiment. As I sit here typing this, I think about the global communities created through applications like Facebook, Twitter, and GitHub. I'm happy to see that these "modern" tools are a great way to further connect users with businesses. Where BBSes existed in the days of yore, we have an instant connection to share and create with others. It's not revolutionary, but evolutionary.

On the hardware side, we have smartphones and tablets. I can't be depressed about the state of the Technology industry as a whole when we have created devices that link us to the global community and information ANYWHERE IN THE WORLD WE ARE. I remember having to wait for the opportunity to use the internet at school before we got it at home, much less having dial up or the transition to any of the N number of devices on me that can connect at a given time. Our industry is actually pretty freaking awesome.

I wanted to say, that I'm "Depressed that the 'quintessentail books' of our industry are from many decades ago". Well, this one is still kinda' true. The software engineering bible, "The Mythical Man Month", was published in 19758. The most recent edition includes a preface that explains why, even after all these years, that book is still relevant. Compilers? The "Dragon Book"9 was published first in 1986. If we look at the "Gang of Four" Design Patterns10 book, it was published in 1994. That's two decades ago, and I have yet to find a better book discussing design patterns. "The Practice of Programming" came out a mere five years later in 199911.

Since 2000, though, most content I find is purely about putting content on a website. Granted, websites have evolved a great deal to something that is FAR more interactive than they every used to be, but is that interaction always needed? This page doesn't feature any fancy javascript interactions besides loading Disqus for comments. Even that is entirely optional when it comes to gathering the content. Was that the end? Have we stopped with the revolutions in tech and moved on to a purely evolutionary standpoint?

Inspired Futures

So how do I break the cycle of cyncism? Frankly put, I don't entirely know that I should. Why? Let's be honest with ourselves, not every idea is a good idea. Why should I use blessed-contrib instead of something like emitting data via Diamond to a Graphite? Why should I adopt Rocket/Appc instead of Docker (If you say because there's a spec that can be supported by multiple implementations in a generic fashion, I return with "Why the hell are you reading this; you clearly get 'it'...")? Why containers instead of virtual machines? What does the new tech offer? Sometimes, it's a hell of a lot of nothing. We, as engineers, don't need to grab the new and shiny. We should roll with what works until it doesn't work and demand pragmatism over "Cool Factors".

I guess the trick is finding things that inspire you. For me, it obviously isn't growning more pages on the internet. I remember the change in attitude the first day I found Elixir. The functional programming paradigm seems like a pleasant shift forward from the day-to-day drag of Object-Oriented, MVC web frameworks. After all, isn't forward the only sane direction to travel in?







  7. If you're looking for a language or paradigm, I'd highly suggest Elixir. It's a fantastic entry to Functional Programming for people familiar with Ruby, Python, etc. 





And I rolled it. That was quick.

Sat 20 July 2013 by Kristofer M White

The girlfriend and I went camping with her family at The Badland. I finally got to go Jeeping. It was great. The first trip out on the trails was great. I pulled up next to a couple (husband and wife, both with their own rigs). As a group, we toured ...

read more

"Operation Rebuild: Failure", or "I'm a sucker for a redhead"

Sat 29 June 2013 by Kristofer M White

Well, that didn't work. I gave up. On top of everything else going on, Veronica's transmission went out. Given this was my daily driver, it was time to move on (I would have kept working if it was just a project car). Enter Josie, a 2013 Jeep Wrangler ...

read more

Operation Rebuild: Restoring Veronica (Part III)

Sun 23 June 2013 by Kristofer M White

I wound up replacing the upstream O2 sensors with a pair NTK sensors (23139 - Upstream Front, 23138 - Upstream Back). I chose NTKs because they were the subcontracted manufacturer for the parts when Jeep made my TJ. They were also significantly cheaper, and had the Jeep Forums Seal of Approval ...

read more
Fork me on GitHub