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

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

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

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

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

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