Tl; Dr:There is too little code reuse in software, particularly at the community level Examples of useless duplication (not-dry) include manyprogramming languages, package managers, data-stores, tools Thiscommunity duplicationmeansengineers have to learn different interfaces to nearly identicalsystems and reduces interoperability of tools
1. Why is there more than one unix/linux package manager?Do we really need a package manager with the same commands but renamed for every programming languages? Do we really need a distinct package manager for each distro?
This leads to a scenario where “learning a language” is more about learning the library than anything else (e.g. “How do timezones work again in PHP?”)
2. MongoDB never should have existed . MongoDB should be a storage engine. The concept of a datastore that adapts its schema on-the-fly and drops relations for speed is okay, but there’s no reason the entire database has to be reinvented to allow this. There’s no reason the entire query syntax has to be reinvented. There’s no reason the security policy has to be reinvented and all the DB drivers. There’s 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.
The same point holds for cassandra (which is basically mysql with sharding built in), elastic search, and even kafka (basically just log part 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 as-needed.
3. Overly-specialized technologies should not exist. People seem to love interview questions about job queues.All job queues should be built on top of a SQL backend so that engineers get the normal benefitsengineers know how to diagnose the system if it fails because it’s a common one (e.g. performance issues, permissions) engineers can always query the system to see what’s happening because it’s using a standardized query language engineers can modify the system if necessary because it provides visibility into its workings engineers can use existing backup, replication, and other technologies to store/distribute the queue (giving interoperability) The effects of creating new systems: Senior Engineers are all set back years relative to junior ones (bad for senior engineers, good for junior engineers) The ecosystem is set back as a whole (all tools, libraries that interact with the old technology are rebuilt for the new one) The company is placed in a precarious position because it now only has junior engineers in the given technology 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-time. Engineers spend so much time memorizing different bad interfaces to new technologies (how their config files work, gotchas and bugs, how their performance scales, how to understand their logs) that the ability for them to progress gets undone. It’s a treadmill effect engineers have to run (keep learning new technologies) just to stay in place. The exceptions:
There are a few exceptions I can think of when a complete rebuild from scratch was an improvement. One would beGit. 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.
The times a rebuild is justified seem to bewhen many of these criteria apply:You’re a known and well-respected name that people trust so much they may standardize on you for convenience (e.g. Linus Thorvalds, Google) The existing systems are all awful in fundamental ways, not simple in simple-patchable ways (e.g. UI) You can make your system backward compatible (C++ allows assembler, Scala allows Java) and thus can reuse existing knowledge and tools You’re so smart and not-average that your system isn’t going to have the myriad of unanticipated flaws that most software systems you want to replace will. For example, angular, backbone, nosql, are all community fails. Your system is already built-in or easily-integrated with existing systems (e.g. JSON being interpretable in all browsers automatically)