5 ms·

I learned three things watching EN snatch defeat from the jaws of victory: 1) There is almost never a case for a total ground up rewrite of your core product.

I learned three things watching EN snatch defeat from the jaws of victory: 1) There is almost never a case for a total ground up rewrite of your core product. Just don’t do it. 2) Don’t abandon the users who made you successful in the first place. They’re the ones who advocate for you and get your foot in the door. 3) real time google docs style collaborative editing is table stakes for this software category. Build your V1 with it in mind. Otherwise you’ll have to do a rewrite later. See 1.

etempleton 4y ago
The thing I learned was that maybe a small successful app or service can just be a small successful app or service and not have to grow indefinitely. At some point it seemed like Evernote became obsessed with growing the revenue / business and not making a better product.
- cooperadymas 4y ago
  In other words, they took VC funding.
seti0Cha 4y ago
Disagree on #3. Social & collaborative features are the bane of my existence. No I don't want to share all my scraps of information, no I don't want to let my friends know what I'm listening to, no, I don't want to publish product purchases I make to twitter. I think a better #3 would be: decide whether your audience is individuals or businesses, then build for that.
- jef_leppard 4y ago
  If you don’t want collaborative editing, don’t use it. I’m saying most users wanted it and started looking elsewhere when EN couldn’t deliver. It’s easier to add a lock on collaboration than to backfill later.
  - hosh 4y ago
    The problem is that the effort to do collaborative editing creates a lot of other problems. I want to be able to just start typing, on my phone. Instead, I have to wait for it to sync. If I am in a place with bad reception, that will take a while. It lags and freezes, all in order to support collaboration that I do not want. I want to add pictures. I want to add links to other notes. I pay for a subscription to get bullet proof cloud backup. Sometimes I want to share notes. I don’t want to collaboratively edit my personal notes with my private thoughts and journal entries. Evernote stopped focusing on that. I might switch over to Muse. It was designed to be local first and uses cdrt for sync.
  - criddell 4y ago
    I think collaborative editing was a mistake. According to Libin circa 2010, Evernote was supposed to be your second brain. Letting other people edit my notes doesn't fit the second brain model (IMHO). I wish Evernote had stayed small and tightly focused on a personal product. Unfortunately, it's hard to sell to individuals compared to businesses, and so that's where their focus went once they had VC money driving the ship.
  - seti0Cha 4y ago
    In addition to what other posters said, there are opportunity and maintenance costs. Building features for use-cases other than mine puts me in the position of wondering whether my use-case is part of the long term vision for the product. I want a note taking app that strives to improve at capturing quick notes. A document collaboration tool that happens to work pretty well for capturing quick notes is less likely to satisfy me long term.
  - bighi 4y ago
    Most EVERNOTE users wanted it? I sincerely doubt that even 20% of Evernote users want that. People that want a collaborative Docs app already have Google Docs. Evernote is mostly a "digital cabinet". It's where notes and documents go to die (in a good way).
    - deleted 4y ago
      [deleted]
- dkarl 4y ago
  I agree and disagree. I agree with you because I think they ruined a perfectly good product by trying to turn it into a "collaboration tool" that they could sell big corporate contracts for. On the other hand, I think collaborative editing could have been integrated seamlessly into the product without ruining or even changing the single-player experience.
- btown 4y ago
  "Collaborative editing" is table stakes for a modern note editor because even in a single user scenario you will have the same user editing the same note from multiple devices with different levels of connectivity. The product needs a reputation that it will not lose its user's edits, nor will it make annoying branch-style merge conflicts. To do this right you have to treat the other device as an almost-adversarial actor. Unless you want "glitchy" to be in the first sentence people use to describe you.
  - digdugdirk 4y ago
    Very good point, one which I admit didn't come to my mind initially. Any recommendations for good methods or good open source implementations of this that can be mined for ideas?
    - spiffytech 4y ago
      CRDTs, and Yjs specifically, are lowering the bar on this. I can't name any products I know are using them, though.
      - chucky123 4y ago
        Figma uses CRDT. And Notion has their own thing based on CRDT(not fact checked)
        Smerity 4y ago
        To note, Figma use something inspired by but not quite CRDTs: > Figma isn't using true CRDTs though. CRDTs are designed for decentralized systems where there is no single central authority to decide what the final state should be. There is some unavoidable performance and memory overhead with doing this. Since Figma is centralized (our server is the central authority), we can simplify our system by removing this extra overhead and benefit from a faster and leaner implementation. > It’s also worth noting that Figma's data structure isn't a single CRDT. Instead it's inspired by multiple separate CRDTs and uses them in combination to create the final data structure that represents a Figma document. https://www.figma.com/blog/how-figmas-multiplayer-technology-works/ https://www.figma.com/blog/how-figmas-multiplayer-technology...
- SergeAx 4y ago
  I have this minset too, but I have one use case for sharing EN notes: when I write articles or short posts which needed to be approved or get an editor touch. I may use Google Docs for it, but there are too many downsides with them compared to EN.
- chillfox 4y ago
  I agree about the general anti social feature sentiment. Collaborative editing makes sense for business users (taking meeting notes) and not much for individuals. That said, the tech that enables collaborative editing is kinda the same that allows solid sync and picking up your note taking session on a different device seconds after you put down another, which is something individuals do benefit from. I like being able to go between my laptop and desktop very fast. Currently with Obsidian and using git for sync it kinda sucks a bit as if I am not careful I get merge conflicts.
  - joker99 4y ago
    I disagree. It even makes sense in a personal environment where I want to collaborate with my wife for example: shared to do lists, shopping lists we edit concurrently, shared ideas for vacations, packing lists, ideas for date nights, important phone numbers in regards to our kids, places and bars we've been to and would recommend to friends and visitors, etc etc. We regularly collaborate on this stuff and for our intents and purposes, apple notes provides all we need
hn_throwaway_99 4y ago
Regarding #1, this is now an often touted recommendation, even by folks like Joel Spolsky whom I greatly admire, but I'm not sure it's the right lesson. For example, I know that Google (at least in the 00s) rewrote huge, major pieces of their infrastructure multiple times and did so successfully. While I agree that broadcasting out a message of "We're going to stop the world and add no new features until we do a ground-up rewrite" is a bad idea, perhaps other lessons could be: 1. Don't write code that's such a spaghetti mess in the first place that you feel the need to throw your hands up and say "nothing can be done except a rewrite". 2. If you do need to do a major rewrite, make sure you have the ability to staff two teams - one doing the rewrite and another maintaining and adding new features to the existing product. 3. Kinda related to number one, but if you have well-organized code to begin with I find it's much easier to do a major rewrite in "sections" (though there are obviously difficulties with this approach).
- bighi 4y ago
  4. If you're going to do the rewrite, don't take many years working on it, just to release a broken product missing lots of core features. 5. If you're releasing a broken product missing core features, don't take many YEARS after release to un-brake your product and build some of the missing features again.
- asdajksah2123 4y ago
  > rewrote huge, major pieces of their infrastructure multiple times and did so successfully I think that's different from a user facing rewrite. I suspect while Google did its infrastructure rewrites, users didn't notice a difference. Additionally, Google probably had the resources to continue delivering features to users while the infrastructure was being developed. The problem with a front end rewrite is (a) things might break and users will notice, and (b) it's hard to deliver new features to users while the front end app itself is being rewritten.
  - hn_throwaway_99 4y ago
    Google isn't the only example here. Heck, just look at the transition from Classic MacOS to OS X. I definitely think Apple would have been dead long ago if they said "A rewrite is too expensive/risky, let's just incrementally improve Classic MacOS". I guess my point is that there are right ways and wrong ways to do ground-up rewrites, and the fact that a lot of people do them the wrong way shouldn't mean the lesson should be to never do them.
bighi 4y ago
I think number 1 could be done, but not like Evernote did. It's been what? 3 years since they released their javascript app, and they still didn't rewrite some important old features. Just last week we got back the option to start writing a note in the title instead of the body. 3 years! I could write an entire Evernote competitor from scratch in 3 years, as a single developer (as a javascript app, not as multiple native apps). And they STILL don't have reliable note-synching. It took them too long, and their app is too crappy. But a GOOD rewrite would have worked just fine.
- pqs 4y ago
  Why is it so hard to implement apparently simple features? This is surprising to me.
- underwater 4y ago
  A rewrite is not the same as a writing a similar app from scratch. You need to worry about deciding what functionality to preserve, what to change, and what to throw away. Most rebuilds either fail because they skip this step and the result is inadequate for the job, or they do this step and get bogged down in the minutiae of locking down requirements, digging into edge cases, and stakeholder management.
- goto11 4y ago
  It is much harder to rewrite an existing product since you have to retain compatibility. If the old version of the app was crap then presumably the persistent data structures are also crap, but you can't discard them. So you end up building a compatibility layer or migration process, but in the end you have to support the same general data model as the old version.
matchagaucho 4y ago
#2 and #3 seem in conflict with each other. I adopted Evernote for its ability to synchronize my checklists and notes across all devices. Collaborating with others was not an initial feature IIRC (?)
lucideer 4y ago
> 1) There is almost never a case for a total ground up rewrite of your core product. Just don’t do it. I've espoused this before, but I've come around to moderating my take on this. "Almost never" is an exaggeration. I agree that they "almost never" work, but that's not the same as there being no case (there's a difference between "should not have done" and "should have done differently". After many years of seeing both play out (rewrites and decided-not-to-rewrites) I'd edit this adage to: "there is almost never a case to rewrite yourself" (for the individual) or "there is almost never a case to get the same team to rewrite" (for management). I'm not saying that engineers can't learn from their own mistakes but if you wrote the software & you think it needs a scratch rewrite rather than a refactor, you're unlikely to have learnt enough within that gap of time to make the rewrite significantly better than a refactor. The other reason for failure outside of the original architect repeating their same mistakes 2nd time around is outsourcing the rewrite. Wholesale outsourcing is an unbelievably inefficient & failure-prone way to build in-house software.
- lazyasciiart 4y ago
  My moderated version: you are almost never going to do better at meeting the same goals with a full rewrite. Even when there is a good case for it, it is unlikely to work out.
- hinkley 4y ago
  > you think it needs a scratch rewrite rather than a refactor, you're unlikely to have learnt enough within that gap of time to make the rewrite significantly better than a refactor. Relentless Refactoring replaces the ship piece by piece while it's under way. If you are effective at it, you can effectively (both definitions) rewrite the entire app with few people being any the wiser. If you are not good at decomposing a problem into digestible, coherent steps, then you are also lousy at Relentless Refactoring. If you can't decompose the problem, your top-down rewrite is statistically guaranteed to fail. Someone somewhere will get lucky, accidentally beating 1:4 odds over and over for 50 failure points, but that person will probably not be you. The people who can Relentlessly Refactor don't need to ask for a top-down rewrite. They just get down to doing it. Therefore most of the people who ask for one are incapable of taking advantage of such permission. Ultimately, the only people who ask for a top-down rewrite are the people who don't deserve it. They believe in do-overs instead of doing the hard work of removing obstacles. They believe in the Second System (without the attendant Syndrome), not in observing and adapting to new information as it becomes available. They have, in essence, trained themselves to continue to misbehave in the face of new wisdom. They will repeat that behavior during the rewrite.
tqi 4y ago
Was there any other company doing real time collaboration in 2008 (when Evernote launched)? IIRC that predates even Google docs, so I wouldn't consider that snatching defeat from the jaws of victory.
kevin_thibedeau 4y ago
Google docs didn't exist when Evernote started. Their competitor was OneNote.
johnxie 4y ago
Agreed on point 3 for modern editors in 2022, as real-time collaboration and collaborative editing are table stakes today if you want to compete. But to give EN credit, when they launched (web 2008?) this was not the case, and a complete rewrite on point 1 could very well be necessary when the new CEO took over recently. We started with OT [1] in mind for V1 of Taskade [2] with the intention to make our editor collaborative, but it was still a bumpy road before we were able to iterate on the product and speed up our dev cycle,. It continues to be a challenge to support the various use cases and customers, as improvements for offline editing, cross-device syncing, and recovery never ends. This problem isn't fully solved and there are no perfect out of box solutions. [1] https://en.wikipedia.org/wiki/Operational_transformation https://en.wikipedia.org/wiki/Operational_transformation [2] https://www.taskade.com https://www.taskade.com
mizzao 4y ago
Notion still doesn't have (3) and I find it compelling enough to continue using. (e.g. when simultaneously editing, text will randomly disappear from one or both writers)

etempleton 4y ago

The thing I learned was that maybe a small successful app or service can just be a small successful app or service and not have to grow indefinitely. At some point it seemed like Evernote became obsessed with growing the revenue / business and not making a better product.

cooperadymas 4y ago
In other words, they took VC funding.

seti0Cha 4y ago

Disagree on #3. Social & collaborative features are the bane of my existence. No I don't want to share all my scraps of information, no I don't want to let my friends know what I'm listening to, no, I don't want to publish product purchases I make to twitter. I think a better #3 would be: decide whether your audience is individuals or businesses, then build for that.

jef_leppard 4y ago
If you don’t want collaborative editing, don’t use it. I’m saying most users wanted it and started looking elsewhere when EN couldn’t deliver. It’s easier to add a lock on collaboration than to backfill later.
- hosh 4y ago
  The problem is that the effort to do collaborative editing creates a lot of other problems. I want to be able to just start typing, on my phone. Instead, I have to wait for it to sync. If I am in a place with bad reception, that will take a while. It lags and freezes, all in order to support collaboration that I do not want. I want to add pictures. I want to add links to other notes. I pay for a subscription to get bullet proof cloud backup. Sometimes I want to share notes. I don’t want to collaboratively edit my personal notes with my private thoughts and journal entries. Evernote stopped focusing on that. I might switch over to Muse. It was designed to be local first and uses cdrt for sync.
- criddell 4y ago
  I think collaborative editing was a mistake. According to Libin circa 2010, Evernote was supposed to be your second brain. Letting other people edit my notes doesn't fit the second brain model (IMHO). I wish Evernote had stayed small and tightly focused on a personal product. Unfortunately, it's hard to sell to individuals compared to businesses, and so that's where their focus went once they had VC money driving the ship.
- seti0Cha 4y ago
  In addition to what other posters said, there are opportunity and maintenance costs. Building features for use-cases other than mine puts me in the position of wondering whether my use-case is part of the long term vision for the product. I want a note taking app that strives to improve at capturing quick notes. A document collaboration tool that happens to work pretty well for capturing quick notes is less likely to satisfy me long term.
- bighi 4y ago
  Most EVERNOTE users wanted it? I sincerely doubt that even 20% of Evernote users want that. People that want a collaborative Docs app already have Google Docs. Evernote is mostly a "digital cabinet". It's where notes and documents go to die (in a good way).
  - deleted 4y ago
    [deleted]
dkarl 4y ago
I agree and disagree. I agree with you because I think they ruined a perfectly good product by trying to turn it into a "collaboration tool" that they could sell big corporate contracts for. On the other hand, I think collaborative editing could have been integrated seamlessly into the product without ruining or even changing the single-player experience.
btown 4y ago
"Collaborative editing" is table stakes for a modern note editor because even in a single user scenario you will have the same user editing the same note from multiple devices with different levels of connectivity. The product needs a reputation that it will not lose its user's edits, nor will it make annoying branch-style merge conflicts. To do this right you have to treat the other device as an almost-adversarial actor. Unless you want "glitchy" to be in the first sentence people use to describe you.
- digdugdirk 4y ago
  Very good point, one which I admit didn't come to my mind initially. Any recommendations for good methods or good open source implementations of this that can be mined for ideas?
  - spiffytech 4y ago
    CRDTs, and Yjs specifically, are lowering the bar on this. I can't name any products I know are using them, though.
    - chucky123 4y ago
      Figma uses CRDT. And Notion has their own thing based on CRDT(not fact checked)
      - Smerity 4y ago
        To note, Figma use something inspired by but not quite CRDTs: > Figma isn't using true CRDTs though. CRDTs are designed for decentralized systems where there is no single central authority to decide what the final state should be. There is some unavoidable performance and memory overhead with doing this. Since Figma is centralized (our server is the central authority), we can simplify our system by removing this extra overhead and benefit from a faster and leaner implementation. > It’s also worth noting that Figma's data structure isn't a single CRDT. Instead it's inspired by multiple separate CRDTs and uses them in combination to create the final data structure that represents a Figma document. https://www.figma.com/blog/how-figmas-multiplayer-technology-works/ https://www.figma.com/blog/how-figmas-multiplayer-technology...
SergeAx 4y ago
I have this minset too, but I have one use case for sharing EN notes: when I write articles or short posts which needed to be approved or get an editor touch. I may use Google Docs for it, but there are too many downsides with them compared to EN.
chillfox 4y ago
I agree about the general anti social feature sentiment. Collaborative editing makes sense for business users (taking meeting notes) and not much for individuals. That said, the tech that enables collaborative editing is kinda the same that allows solid sync and picking up your note taking session on a different device seconds after you put down another, which is something individuals do benefit from. I like being able to go between my laptop and desktop very fast. Currently with Obsidian and using git for sync it kinda sucks a bit as if I am not careful I get merge conflicts.
- joker99 4y ago
  I disagree. It even makes sense in a personal environment where I want to collaborate with my wife for example: shared to do lists, shopping lists we edit concurrently, shared ideas for vacations, packing lists, ideas for date nights, important phone numbers in regards to our kids, places and bars we've been to and would recommend to friends and visitors, etc etc. We regularly collaborate on this stuff and for our intents and purposes, apple notes provides all we need

hn_throwaway_99 4y ago

Regarding #1, this is now an often touted recommendation, even by folks like Joel Spolsky whom I greatly admire, but I'm not sure it's the right lesson. For example, I know that Google (at least in the 00s) rewrote huge, major pieces of their infrastructure multiple times and did so successfully. While I agree that broadcasting out a message of "We're going to stop the world and add no new features until we do a ground-up rewrite" is a bad idea, perhaps other lessons could be: 1. Don't write code that's such a spaghetti mess in the first place that you feel the need to throw your hands up and say "nothing can be done except a rewrite". 2. If you do need to do a major rewrite, make sure you have the ability to staff two teams - one doing the rewrite and another maintaining and adding new features to the existing product. 3. Kinda related to number one, but if you have well-organized code to begin with I find it's much easier to do a major rewrite in "sections" (though there are obviously difficulties with this approach).

bighi 4y ago
4. If you're going to do the rewrite, don't take many years working on it, just to release a broken product missing lots of core features. 5. If you're releasing a broken product missing core features, don't take many YEARS after release to un-brake your product and build some of the missing features again.
asdajksah2123 4y ago
> rewrote huge, major pieces of their infrastructure multiple times and did so successfully I think that's different from a user facing rewrite. I suspect while Google did its infrastructure rewrites, users didn't notice a difference. Additionally, Google probably had the resources to continue delivering features to users while the infrastructure was being developed. The problem with a front end rewrite is (a) things might break and users will notice, and (b) it's hard to deliver new features to users while the front end app itself is being rewritten.
- hn_throwaway_99 4y ago
  Google isn't the only example here. Heck, just look at the transition from Classic MacOS to OS X. I definitely think Apple would have been dead long ago if they said "A rewrite is too expensive/risky, let's just incrementally improve Classic MacOS". I guess my point is that there are right ways and wrong ways to do ground-up rewrites, and the fact that a lot of people do them the wrong way shouldn't mean the lesson should be to never do them.

bighi 4y ago

I think number 1 could be done, but not like Evernote did. It's been what? 3 years since they released their javascript app, and they still didn't rewrite some important old features. Just last week we got back the option to start writing a note in the title instead of the body. 3 years! I could write an entire Evernote competitor from scratch in 3 years, as a single developer (as a javascript app, not as multiple native apps). And they STILL don't have reliable note-synching. It took them too long, and their app is too crappy. But a GOOD rewrite would have worked just fine.

pqs 4y ago
Why is it so hard to implement apparently simple features? This is surprising to me.
underwater 4y ago
A rewrite is not the same as a writing a similar app from scratch. You need to worry about deciding what functionality to preserve, what to change, and what to throw away. Most rebuilds either fail because they skip this step and the result is inadequate for the job, or they do this step and get bogged down in the minutiae of locking down requirements, digging into edge cases, and stakeholder management.
goto11 4y ago
It is much harder to rewrite an existing product since you have to retain compatibility. If the old version of the app was crap then presumably the persistent data structures are also crap, but you can't discard them. So you end up building a compatibility layer or migration process, but in the end you have to support the same general data model as the old version.

matchagaucho 4y ago

#2 and #3 seem in conflict with each other. I adopted Evernote for its ability to synchronize my checklists and notes across all devices. Collaborating with others was not an initial feature IIRC (?)

lucideer 4y ago

> 1) There is almost never a case for a total ground up rewrite of your core product. Just don’t do it. I've espoused this before, but I've come around to moderating my take on this. "Almost never" is an exaggeration. I agree that they "almost never" work, but that's not the same as there being no case (there's a difference between "should not have done" and "should have done differently". After many years of seeing both play out (rewrites and decided-not-to-rewrites) I'd edit this adage to: "there is almost never a case to rewrite yourself" (for the individual) or "there is almost never a case to get the same team to rewrite" (for management). I'm not saying that engineers can't learn from their own mistakes but if you wrote the software & you think it needs a scratch rewrite rather than a refactor, you're unlikely to have learnt enough within that gap of time to make the rewrite significantly better than a refactor. The other reason for failure outside of the original architect repeating their same mistakes 2nd time around is outsourcing the rewrite. Wholesale outsourcing is an unbelievably inefficient & failure-prone way to build in-house software.

lazyasciiart 4y ago
My moderated version: you are almost never going to do better at meeting the same goals with a full rewrite. Even when there is a good case for it, it is unlikely to work out.
hinkley 4y ago
> you think it needs a scratch rewrite rather than a refactor, you're unlikely to have learnt enough within that gap of time to make the rewrite significantly better than a refactor. Relentless Refactoring replaces the ship piece by piece while it's under way. If you are effective at it, you can effectively (both definitions) rewrite the entire app with few people being any the wiser. If you are not good at decomposing a problem into digestible, coherent steps, then you are also lousy at Relentless Refactoring. If you can't decompose the problem, your top-down rewrite is statistically guaranteed to fail. Someone somewhere will get lucky, accidentally beating 1:4 odds over and over for 50 failure points, but that person will probably not be you. The people who can Relentlessly Refactor don't need to ask for a top-down rewrite. They just get down to doing it. Therefore most of the people who ask for one are incapable of taking advantage of such permission. Ultimately, the only people who ask for a top-down rewrite are the people who don't deserve it. They believe in do-overs instead of doing the hard work of removing obstacles. They believe in the Second System (without the attendant Syndrome), not in observing and adapting to new information as it becomes available. They have, in essence, trained themselves to continue to misbehave in the face of new wisdom. They will repeat that behavior during the rewrite.

tqi 4y ago

Was there any other company doing real time collaboration in 2008 (when Evernote launched)? IIRC that predates even Google docs, so I wouldn't consider that snatching defeat from the jaws of victory.

kevin_thibedeau 4y ago

Google docs didn't exist when Evernote started. Their competitor was OneNote.

johnxie 4y ago

Agreed on point 3 for modern editors in 2022, as real-time collaboration and collaborative editing are table stakes today if you want to compete. But to give EN credit, when they launched (web 2008?) this was not the case, and a complete rewrite on point 1 could very well be necessary when the new CEO took over recently. We started with OT [1] in mind for V1 of Taskade [2] with the intention to make our editor collaborative, but it was still a bumpy road before we were able to iterate on the product and speed up our dev cycle,. It continues to be a challenge to support the various use cases and customers, as improvements for offline editing, cross-device syncing, and recovery never ends. This problem isn't fully solved and there are no perfect out of box solutions. [1] https://en.wikipedia.org/wiki/Operational_transformation https://en.wikipedia.org/wiki/Operational_transformation [2] https://www.taskade.com https://www.taskade.com

mizzao 4y ago

Notion still doesn't have (3) and I find it compelling enough to continue using. (e.g. when simultaneously editing, text will randomly disappear from one or both writers)