NoSQL database<\/a> solutions, html parsing, regex, etc). Wrapping libcurl, for example, is a great way to stay dry.<\/p>\n\n\n\nThis leads to a scenario where \u201clearning a language\u201d is more about learning the libraries than anything else (e.g. \u201cHow do timezones work again in PHP?\u201d)<\/p>\n\n\n\n
3. Did MongoDB <\/strong>really need to exist as as a standalone application?<\/strong> What if <\/em>MongoDB had simply been a storage engine?<\/em> The concept of a datastore that adapts its schema on-the-fly and drops relations for speed is okay, but does that justify creating an entirely new data-storage technology to that end? This means millions of engineers learning a new query syntax for a potentially temporary technology. Same with the security policy, all the DB drivers. There\u2019s no reason all the tools to get visibility (sql pro) and backup the database need to be reinvented. Plus, if it were just a storage engine, migrating tables to InnoDB would be easier.<\/p>\n\n\n\nThe same point holds for cassandra (which is basically mysql with sharding and more sophisticated replication built in), elastic search, and even kafka (basically just WAL of mysql without columns). For example, a kafka topic could be seen as a table with the columns: offset, value. Remember storage engines can process different variations on SQL to handle any special functionality or performance characteristics as-needed (I do recognize what I\u2019m describing is easier said than done, but recommend it nonetheless).<\/p>\n\n\n\n
4. Overly-specialized technologies should not exist (unless built directly around a general technology)<\/strong>. You ever see a fancy dinner-set, where for \u201cconvenience\u201d people are offered 5 forks and spoons, each one meant to be used slightly differently for a slightly different task? That\u2019s how I feel about overly-specialized technologies. For example, people seem to love job queues. What if all job queues were implemented on top of a SQL backend so that engineers get the normal benefits:<\/p>\n\n\n\n\n- engineers know how to diagnose the system if it fails because it\u2019s a known system (e.g. performance issues, permissions)<\/li>\n\n\n\n
- engineers can always query the system to see what\u2019s happening because it\u2019s using a standardized query language<\/li>\n\n\n\n
- engineers can modify the system if necessary because it provides visibility into its workings<\/li>\n\n\n\n
- engineers can use existing backup, replication, monitoring, and other technologies to store\/distribute the queue (giving interoperability)<\/li>\n<\/ol>\n\n\n\n
<\/h2>\n\n\n\nSection 2: What\u2019s the result of all this?<\/strong><\/h2>\n\n\n\n\n- Every time a brand-new hype technology is introduced senior Engineers are all set back years relative to junior ones (which is bad for senior engineers, good for junior engineers)<\/li>\n\n\n\n
- The ecosystem is set back as a whole (all tools, libraries that interact with the old technology are rebuilt for the new one)<\/li>\n\n\n\n
- Company is placed in an uncomfortable position because it now only has junior engineers in the given technology. When I was junior, I worked at a startup that accidentally lost most of their customers\u2019 phone numbers because their PHP driver for mongo would convert numeric strings to numbers, and phone numbers would overflow the default integer, resulting in no fatal errors but simply negative phone numbers.<\/li>\n\n\n\n
- The company runs the risk of being saddled with a technology that will be dropped (e.g. couchdb, backbone) and will require a rewrite back to a standard technology or be perceived as behind-the-times.<\/li>\n\n\n\n
- Slow-learning \/ part-time engineers must keep pace with the changing landscape or face irrelevance. Those that can\u2019t learn several technologies a year will stumble.<\/li>\n\n\n\n
- Fast paced-engineers will lose half of their learning capacity on trivialities and gotchas of each technology\u2019s idiosyncrasies (e.g. why can\u2019t apache configs and nginx configs bare any resemblance to each other?). Once these technologies are phased out (e.g. now it\u2019s mostly cloud ELBs) all of that memorization is for naught. It\u2019s a treadmill effect \u2013 engineers have to sprint (keep learning new technologies) to move forward at all, walk just to stay in place, and if you can\u2019t keep pace with the treadmill you fall behind.Quick aside \u2013 I think things moving to the cloud is probably one of the most outstanding dev benefits I\u2019ve seen in my life. However it continues to illustrate the point in that if different cloud providers don\u2019t standardize then the whole development community is slowed down.<\/li>\n<\/ul>\n\n\n\n
Section 3: The exceptions<\/strong><\/h2>\n\n\n\nThere are a few exceptions I can think of when a complete rebuild from scratch was an improvement. One would be Git. In a few months, one of the most prominent software geniuses of our era invented a source-control system so superior to everything else that it has been adopted universally in a few years, despite the intimidating interface.<\/p>\n\n\n\n
The times a rebuild is justified seem to be when many of these criteria apply:<\/p>\n\n\n\n
\n- You\u2019re a known and well-respected name that people trust so much the community might\u00a0standardize<\/em><\/strong> on what you make\u00a0(e.g. Linus Torvalds, Google)<\/li>\n\n\n\n
- The existing systems are all awful in fundamental ways, not simple in easily-patchable ways. You\u2019ve got the ability, time [and we\u2019re talking at least a decade of support], money to dedicate yourself to this project (git, aws, gmail, jquery in 2006)<\/li>\n\n\n\n
- You can make your system backward compatible (e.g. C++ allows C, C allows assembler, Scala allows Java, many game systems and storage devices can read previous-generation media) and thus can reuse existing knowledge, libraries, and tools<\/li>\n\n\n\n
- You\u2019re so smart and not-average that your system isn\u2019t going to have the myriad of unanticipated flaws that most software systems you want to replace will. For example, angular, backbone, nosql, are all things that might, in hindsight, have been not worth learning. Of the current high-buzz languages as of me writing this (Go, Clojure, Haskell, Ruby) it\u2019s open to speculation which will stand the test of time.<\/li>\n\n\n\n
- Your system is already built-in-to or easily-integrated-with existing systems (e.g. JSON being interpretable in all browsers automatically, moving your service to the web where it will work cross-platform and be accessible without installation)<\/li>\n<\/ul>\n\n\n\n
Section 4: What can one do?<\/h2>\n\n\n\n\n- Learn the technologies that have stood the test of time: linux cli, c++\/java, javascript, SQL<\/li>\n\n\n\n
- Wait years before adopting a technology in professional use for a major use-case\u2013 let other companies be the guinea pig<\/li>\n\n\n\n
- Be judicious in usage of new technologies. For whatever reason, it\u2019s culturally \u201ccool\u201d to know about the \u201cnext big thing,\u201d but it\u2019s better to be late and right than early and wrong.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
Tl; Dr: Section 1: Some examples 1. Why is there more than one unix\/linux package manager? Do we really need a different package manager with the same commands but renamed for each programming language? Why do we need a distinct package manager for each distro? 2. Nobody seems to admit it, but Php, Ruby, Python, and Javascript are…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-29","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/think-twice.me\/index.php?rest_route=\/wp\/v2\/posts\/29","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/think-twice.me\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/think-twice.me\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/think-twice.me\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/think-twice.me\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=29"}],"version-history":[{"count":1,"href":"https:\/\/think-twice.me\/index.php?rest_route=\/wp\/v2\/posts\/29\/revisions"}],"predecessor-version":[{"id":30,"href":"https:\/\/think-twice.me\/index.php?rest_route=\/wp\/v2\/posts\/29\/revisions\/30"}],"wp:attachment":[{"href":"https:\/\/think-twice.me\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=29"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/think-twice.me\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=29"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/think-twice.me\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=29"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}