[jef_leppard]

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.

[seti0Cha]

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.

[btown]

"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]

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]

CRDTs, and Yjs specifically, are lowering the bar on this. I can't name any products I know are using them, though.

[chucky123]

Figma uses CRDT. And Notion has their own thing based on CRDT(not fact checked)

[Smerity]

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...

[tionis]

HedgeDoc uses Y.js under the hood

[jef_leppard]

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]

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.

[bighi]

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).

[8n4vidtmkvmk]

I've used the collaborative feature in google docs only a few times even tho i write google docs like daily. most docs are authored by 1 person. the side comments, however, are invaluable

[criddell]

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]

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.

[dkarl]

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.

[chillfox]

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]

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

[SergeAx]

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.

[lucideer]

> 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.

[hinkley]

> 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.

[danrocks]

I enjoy Relentess Refactoring as much as the next guy, but one dimension here is that it is much easier to do in a headless app (or in the backend) than in an app with a major UI. At some point there must be a complete switch from the old UI to the new UI, and that step is extremely complex. It also invites a big rewrite, in an almost irresistible way - "since we'll change the UI, let's just do it from the ground up".

[hinkley]

The main lesson of the CI/CD era is that pain is information and ignoring it until later just makes things worse.

"Let's replace the whole UI at once" and "Let's replace the whole app at once" are bandaid-ripping activities, and the point of ripping off a bandaid is to get it over with before your pain receptors have a chance to tell you what an asshole you are right now. I'm sure most people have at least one experience, of their own or of someone they know, where ripping off the bandaid took a chunk of skin with it, possibly creating a bigger wound than the bandage originally covered.

[ska]

> unlikely to have learnt enough

There is an important caveat here - sometimes the original is rough not because you didn't know how to do it better, but because you were emphasizing speed and flexibility e.g. very early stage startup and you don't really understand the product here.

[see also, ship the prototype problem]

[lazyasciiart]

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.

[runlevel1]

A successful rewrite of a core product requires a mix of peers: Old blood, who know the wins and sins of the past, and new blood who'll bring a fresh perspective.

[hn_throwaway_99]

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).

[asdajksah2123]

> 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]

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.

[Kye]

Replacing one mature operating system with another, which itself was based on one even more mature, and adding stuff is not quite a rewrite. That was more like how Microsoft moved NT into its consumer OS. It was a bit of a mess but had a clear payoff once everything was updated or obsoleted. NT and BSD were both battle-hardened long before anyone thought to put them in consumer systems.

[goto11]

Apple actually tried to rewrite the classic OS from scratch with the Copland project and it failed (at enormous cost). OS X was not a rewrite-from-scratch since they acquired an already working OS from Next. The had to add compatibility layers (which was in itself a major undertaking) but they didn't write the OS from scratch.

[tomjen3]

Spolskys point back then was that you couldn't stop the world, do nothing for two years and then come back with your rewritten product.

It was not that you couldn't rewrite part of the product here and there over time, and end up with something that is only the same as the original product in the way the greek ship was.

[bighi]

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.

[johnxie]

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

[2] https://www.taskade.com

[etempleton]

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]

In other words, they took VC funding.

[bighi]

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.

[goto11]

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.

[underwater]

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.

[pqs]

Why is it so hard to implement apparently simple features? This is surprising to me.

[tqi]

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]

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

[mizzao]

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)

[matchagaucho]

#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 (?)