When the question of something being a "killer" of another piece of software comes up, e.g.
Deno: Node.js Killer? Introduction & Demo | Ryan Dahl
codeSTACKr ・ May 12 '20
#deno
#webdev
#tutorial
#beginners
I tend to think that regardless of how great the ideas are, typically the old stuff sticks around because it's hard to migrate off the old stuff. What are some examples of software with the most thoughtful adoption path?
Top comments (6)
I think software that is easier to adopt is additive instead of a replacement. If you have plain JavaScript and want to use TypeScript, you can probably set it up without having to refactor code (or at least limit the upfront refactoring). In that regard, I think TypeScript has a thoughtful adoption path because it is not a new language entirely and was designed with that in mind. I think this extends to other language's optional type systems and superset languages like SCSS. But even with that, there still might be some gotchas and pain points to adopting it in an existing codebase.
For anything else that is more of a replacement rather than supplemental (like going from Node to Deno), I'm not sure if there is a great adoption path. Going for the full application rewrite is usually not a good idea because it may take a while, cost a lot, and there is no guarantee that the code or system will be any better off than it is now. Doing an incremental adoption also has its issues because you have to develop new features in the new system while maintaining and deprecating things in the old system. Depending on how monolithic things were in the old system, it may be time consuming to get the two to play nicely together or get to feature parity.
I think the thoughtful adoption path for anything is asking: why? Is there something wrong with the existing system that it will solve? If not, stay on the old system until it makes good business sense to think about adopting something else.
Kind of a weird example: Notion.
They knew there were many users that didn't like Evernote but didn't want to switch platforms because there was so much stuff they had documented in Evernote. Their import tool allowed new user to copy everything from evernote with one click.
Their import tool also works with other platforms including Asana, Google Docs and Quip. On top of that because of their embed and upload blocks you can include anything you want (even services they didn't think of in their current system).
So uhmm, the point:
If you allow users to switch without too much effort and make it as easy as possible to use it within (or on top of) their existing workflow there is a big chance more users will adopt it.
I don't know if this fits the bill, but I found migrating from Windows 7 to Windows 10 simple. Do a back up, download the tool and let it run. I don't recall any compatibility issues.
Upgrading Ubuntu 16 to 18 was not so easy. It took me hours to figure out how to get online, and there are still other issues. I should probably do a format and reinstall.
This topic reminds me of something I read about designing your code “optimizing for change” rather than trying to predict the future and enforcing behaviours
Having used Asana quite extensively I think they have a great onboarding experience and give really good examples and tutorials when it comes to transitioning to the platform.
Sure, it offers imports from some other software, but two of the stand out approaches for me, are:
Finally (echoing some of the other comments), software that, where possible, allows you to build on what you already have is useful and gradually employ more powerful parts of it, rather than overwhelming you all at once.
Anything that introduces loads of friction is going to turn people away.
Some tips for refactoring