In our industry, technological hype has a bad tendency to work like a ratchet. We sing the praises of the various systems we use, but even after using them for a while and seeing that the hype doesn’t match reality, we don’t knock them back down.
Over the last few decades we’ve seen big pushes for tools like XML, Scala, PHP, MySQL, CouchDB, Erlang, Mnesia, CoffeeScript, Node, Rails, Django, MongoDB, Meteor, Ember, Angular, React, Riak, Clojure, Cassandra, Go, and countless others. More recently, the industry’s seen enough saturation that fatigue has lead to a bit more skepticism, but we can still see the same signs of of ongoing pushes, even if somewhat more tempered (e.g. Rust, Elixir, Kotlin, Crystal, …).
Some of these tools have withstood the test of time and are still fine choices for a new technology stack. On the other hand, a good number of them are not. Trade offs aside, existential problems like a pathologic lack of runtime safety, a decaying ecosystem, or a design that leads to burdensome operation become apparent with use, and make their avoidance perfectly rational. Sometimes we make mistakes, or the state of the art improves, and ideas that we originally thought to be good hit the end of their useful lifetime.
It’s a very human thing to do to withhold criticism. There are humans on the other end of all this technology, and frequently they’re even humans that we know and like. It’s also rarely personally helpful to speak ill of systems that realistically speaking, we’re going to be married to for some time to come.
But we should consider the ramifications of staying silent – by withholding information on the bad technology in our stacks, we’re cheating people and companies who aren’t using it yet, but may yet adopt its use. By articulating problems and trade offs, you’ll better inform decisions and potentially save millions of hours of future productivity that would have otherwise been sacrificed to the altar.
Disastrous pitfalls, vampiric operational overhead, chronic underdesign, or even just obsolescence are never in the manual, and often not obvious until you’re already waist deep. By being on the inside of these things, you have access to special insight that other people can’t get without fully investing themselves at great expense.
This isn’t to say that we should unduly sling mud, but pieces that are honest, detail-oriented, thoroughly researched, but also critical, might be the best way that you can help your fellow builders.
Did I make a mistake? Please consider sending a pull request.