> 1. Why would it be particularly difficult for them to have soft deletes in Rails or at scale?
I don't know the internals of Github. But we had soft-delete dragging down our database. Indexing, for one, becomes tough.
It also presumes everything lives in a single, canonical, transactional database. In real life, anything of scale, with legacy lives in multiple services. There'll be caches, search-indexes (elastic etc), data-lakes, leader/follower clusters and whatnot. Propagating a "delete" command is no easier or harder in such a setup, than propagating a "flag" which has severe business and security implications.
2. Like the article suggests, additional UX improvements could be made besides making it possible to restore a backup or providing an undo action.
Yup. My point was that with e.g. Event-sourced or Command pattern, you don't even need that whole UI in the first place. There could be a 20 minute "undo" somewhere. Or an "undo" that remains active untill another non-compatible command renders undoing unavailable. This is a common pattern. Which was invented decades ago, and is still used everywhere to solve this exact problem.
Why invent dialogs, soft-deletes, etc, when the problem is solved, done and non-existent, given you make the right choices? Why do software engineers insist on re-inventing wheels every few years rather than grab existing, proven and solid solutions for this?¹
3. I feel you are ignoring the fact that technology-wise it was probably Rails along with its MVC model that got them into their scale in the first place.
Why do you feel this? Rails comes with tradeoffs. I'm not saying "rails was a bad choice" But I'm saying "the choice for Rails brings the tradeoffs that e.g. Undo is hard".
Saying that "it is easy in Rails" is both disingenuous and unfair: there are hundreds of Gems, some of which grown to enormous project almost the size of entire ActiveRecord itself, to tackle these problems: it isn't easy. Papertrail, for example is a magnificent monster. "just drop in papertrail" really is not a solution, it's a problem.
> 4. Had they focused on a more exotic architecture from day one, the UX of other features on the site could've been significantly worse.
I.e. "tradeoffs".
¹ The answer, I'm afraid, is a mix of the doubling-of-developers-every-four-years (forever september), NIH, and unwillingness to invest time in learning the foundations layed out in the past decades. The last is what bothers me most.
> Why do software engineers insist on re-inventing wheels every few years rather than grab existing, proven and solid solutions for this?¹
For one thing, because it works very well and is much easier to wrap your head around than the command pattern (much less undoing a command, and keeping track of which commands make incompatible changes).
These things are worth the effort if you are going to build an app that will be around for ten years and serve an existing market. Much harder to justify if you are still figuring out what you actually need to do.
Like, I agree with you that most developers just don’t know about it yet, and therefore don’t use it, but that’s also a factor of MVC just being the right choice for 90% of all apps, and easier to get started with.
I don't know the internals of Github. But we had soft-delete dragging down our database. Indexing, for one, becomes tough.
It also presumes everything lives in a single, canonical, transactional database. In real life, anything of scale, with legacy lives in multiple services. There'll be caches, search-indexes (elastic etc), data-lakes, leader/follower clusters and whatnot. Propagating a "delete" command is no easier or harder in such a setup, than propagating a "flag" which has severe business and security implications.
2. Like the article suggests, additional UX improvements could be made besides making it possible to restore a backup or providing an undo action.
Yup. My point was that with e.g. Event-sourced or Command pattern, you don't even need that whole UI in the first place. There could be a 20 minute "undo" somewhere. Or an "undo" that remains active untill another non-compatible command renders undoing unavailable. This is a common pattern. Which was invented decades ago, and is still used everywhere to solve this exact problem.
Why invent dialogs, soft-deletes, etc, when the problem is solved, done and non-existent, given you make the right choices? Why do software engineers insist on re-inventing wheels every few years rather than grab existing, proven and solid solutions for this?¹
3. I feel you are ignoring the fact that technology-wise it was probably Rails along with its MVC model that got them into their scale in the first place.
Why do you feel this? Rails comes with tradeoffs. I'm not saying "rails was a bad choice" But I'm saying "the choice for Rails brings the tradeoffs that e.g. Undo is hard".
Saying that "it is easy in Rails" is both disingenuous and unfair: there are hundreds of Gems, some of which grown to enormous project almost the size of entire ActiveRecord itself, to tackle these problems: it isn't easy. Papertrail, for example is a magnificent monster. "just drop in papertrail" really is not a solution, it's a problem.
> 4. Had they focused on a more exotic architecture from day one, the UX of other features on the site could've been significantly worse.
I.e. "tradeoffs".
¹ The answer, I'm afraid, is a mix of the doubling-of-developers-every-four-years (forever september), NIH, and unwillingness to invest time in learning the foundations layed out in the past decades. The last is what bothers me most.