[vaishnavsm]

I really like this post.

While the author clearly feels bad about the fact that they've lost his community and that GitHub didn't restore it (which is honestly what any of us would've felt under similar circumstances), they're also focusing towards the future and using their personal experience as a parable all of us can learn from.

Lesson 1 on UI design I think is really important. I often think scary popup boxes are enough to get people to think about what they're doing, but this example clearly demonstrates that what's important is to use design not to scare (alone?), but to convey the information which makes a dangerous action dangerous as well. I also really like the fact that when the action isn't dangerous, the distractions ("Type this repo's name", etc) just go away. It's super intuitive, and (for a newbie designer like me) really helps build an intuition for various design principles put in action.

Lesson 2, which was to use soft deletes, is something I have more thoughts about. I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic? If anyone's aware of a standard way to accomplish this, please do let me know. Of course, the best way may just be to simplify the model so they aren't needed at all haha.

As designers and developers we've been given a chance to sharpen our toolkit. Thanks, HTTPie! You've gained a new star :)

Edit: Changed GitHub couldn't restore to GitHub didn't restore, as pointed out by @ncmncm (https://news.ycombinator.com/item?id=31033758#31034195)

[cmeacham98]

I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website".

Yes, GitHub probably should show the stars in the warning UI, and hopefully that will prevent some of these mistakes. But GitHub makes it pretty hard to make this mistake already - the author had to _type out_ the name of the repo they wanted deleted into the warning box. At that point, it's hard to believe the author when they claim that this one addition to the warning UI would have definitely stopped them when they weren't paying enough attention to notice they had typed the entirely wrong repo into the confirmation box.

[wpietri]

I suggest you read "The Field Guide to Understanding 'Human Error'". You'd learn a lot.

https://www.amazon.com/Field-Guide-Understanding-Human-Error...

My view is that expecting humans to stop making mistakes is much less effective than fixing the systems that amplify those mistakes into large, irreversible impacts.

[mynameisvlad]

This, 1000x this.

It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future".

As a species, we will always take shortcuts. If a mental pathway doesn't need to be exercised to do something, it won't be. If we see the same popup a hundred times, we're going to ignore the contents by the 100th time because we're used to it.

But it shouldn't be possible to make this mistake if this was designed properly and in a way that made it clear that what you're about to do is actually dangerous and not "dangerous" like the other dozen times you've seen the same message.

[klabb3]

Yeah. A warning that can be pattern matched by a human brain, that is just a routine action, will result in autopilot behavior. Flipping early repo visibility is common, I assume. Flipping visibility of 100+ star repos is likely much less common. So having a separate warning in that case might help you snap out of autopilot due to novelty.

A common knee-jerk reaction to "users aren't taking our warnings seriously" is making the warning look more scary and involving more (mechanical) steps – such as two confirmations instead of one. Well, that's pattern matchable and subject to desensitization.

Like the article states, it's more efficient to instead show what you're about to remove, i.e. a summary of the content as opposed to an identifier, then you get both novelty and proportional scariness, depending on how "big" it is.

https://en.m.wikipedia.org/wiki/Alarm_fatigue

[chefandy]

Pretty much agree— Universal human fallibility is not an avoidable moral failure, but looking down on those who've made, admitted, and taken responsibility for simple mistakes sure is. Unrealistic assumptions about people's attention, processing capability, and physical capabilities may be the greatest hurdle when trying to actually solve people's problems with software. It can even be a safety issue— consider the Therac 25 incident.

That said, superlatives like "impossible" aren't realistic here. As long as an action is possible, it is also possible to fuck it up. The challenge screen does require typing in the repo name which is a pretty solid attention-getter. It would be nice to list the important side effects in big angry letters but I'll bet the list of side-effects that are important to some people would be pointlessly long. Maybe a sanity check requiring repos with extremes in certain metrics to get a sanity check from support first— but I have had some preeeeettty protracted response times from GitHub support.

[mynameisvlad]

> I'll bet the list of side-effects that are important to some people would be pointlessly long.

There's many good ways to design this that wouldn't result in pointlessly long lists (which is another problem). You don't need to expose everything that will happen when you do an action, just the "most important".

With unlimited budget, you could compare a bunch of metrics to a baseline to figure out what might be important. Have a lot of stars, way more than the average? That would be nice to highlight. Only have a normal number of forks? Probably less important to highlight that. At the end of the day, Github repos aren't extremely unique. Sure there's probably extremely rare edge cases, but for most repos, comparing against a relatively small number of metrics should get enough to paint a picture of what might get broken. Everything else can be hidden behind a "... and X more" if people are curious.

This both highlights the most important things that might happen, and also provide people with an action to do before confirming, hopefully helping to break the autopilot at the same time.

[ryandrake]

Warnings are good but not perfect. At the end of the day, you can’t help everyone with just warnings. You could make the UI bright flashing red, with a skull and crossbones, have it say “Never invoke this: it will delete all your data and kill your dog. Please type ‘I_WANT_CANCER’ to continue.” And users will do it. It can’t be helped. The only (admittedly hard) way is UNDO.

[chefandy]

You assume the metrics you have are sufficient to determine intent and importance, that your users needs are uniform enough for those determinations apply, and discount the possibility of making things worse by communicating the wrong thing. These assumptions perennially land developers and inexperienced designers in hot water designing things like this.

> "most important"

Yes— the problem is determining the most important metrics for the human who's reading the dialog. Sorting the second part is a lot more difficult than the first.

> With unlimited budget

This framing is only useful to determine what behaviors would be great, not feasibility. We seem to both agree on the ideal behavior but not on the feasibility.

> you could compare a bunch of metrics to a baseline to figure out what might be important.

Important to whom?

> Have a lot of stars, way more than the average? That would be nice to highlight. Only have a normal number of forks? Probably less important to highlight that.

Average for what? Just average for everybody? For the deprecated SlackTextViewController which has vastly higher numbers overall than the unmeasurably more important net-snmp? What about for repos that serve as core functionality to frameworks that only care about forks? XML Schemas that people refer to but never interact with? What about for a company that doesn't care about stars because they're incredibly popular outside of that repo but it's critical for them to monitor the small number of people who've forked their repo?

> Sure there's probably extremely rare edge cases, but for most repos, comparing against a relatively small number of metrics should get enough to paint a picture of what might get broken.

The repo about which you said this mistake should not have been possible was an extremely rare edge case. The article went to great lengths to explore just how fantastically different this repo was. And if you're talking about painting pictures you're using the wrong medium. More information can make the message more pointed but only if it's brief and extremely relevant. If it's not, it's going to reduce the focus on the danger message.

> Everything else can be hidden behind a "... and X more" if people are curious.

Aaaand we come full circle. The whole point of this is to put the metrics most important to that user right in front of their face in bold type because that's going to stop autopilot mistakes. If it's hidden, it failed. Beyond that, the order in which you list things connotes importance— closer to the beginning means more important. Being hidden connotes far lesser importance. If you put the wrong things at the top and the right things behind a click then the autopilot user subconsciously assumes they'd care about the hidden things even less. You're increasing the risk of failure rather than decreasing it. If you're going to highlight anything, you better highlight the right thing.

The existing dialog is pretty clear that you should investigate what it does before you actually execute the command without giving people false clues, and that may be the best compromise. You don't convey false impressions but still convey danger.

> At the end of the day, Github repos aren't extremely unique.

From a quantitative perspective they're not incredibly diverse, even if they're probably more diverse than you imagine. What is immeasurably diverse is the roles those software packages serve, the people who interact with them, and what they need to accomplish their goals. Assuming you can boil that down to a heuristic using available data is something that needs to be concretely proven— not assumed.

[necovek]

It sounds like you've never been part of an engineering organization (I know you have since you bring up unlimited budget ;)

It is obviously possible to design a much better, contextual warning with (more) relevant details highlighted. How much time is usually set aside for those?

And yet, it's never going to stop mistakes.

And how many other places like these are there in a large service like GitHub?

A much better way to fix this is to expect mistakes and make it possible to revert instead. Soft deletes can make that trivial to implement for the most part too (except in GDPR like cases where you've got to really remove stuff).

[wpietri]

> The challenge screen does require typing in the repo name which is a pretty solid attention-getter.

This is not quite correct. In requires inputting the repo name. It's attention-getting the first time. But recently with some colleagues as part of a handoff we went through 50+ repos and archived the irrelevant ones. Very quickly the person doing the actual archiving went from typing to just copy-pasting the repo names. For programmers, copy-pasting from one spot to another can become very mechanical.

So I think this UI choice works well for something that is done very occasionally. But it's no better if people are in the habit. Whereas showing novel information about the cost of the choice would be helpful in breaking the routine. Then could then also make it so that they had to type something only when the operation has a high cost, and what they typed could be something not directly copy-pasteable.

[chefandy]

That's fine. The goals of designing a sanity check prompt to snap people out of autopilot are entirely different from goals you might have in a security system— their being defeatable isn't even a flaw. Jersey barriers vs rumble strips.

If someone deliberately doing the same thing over-and-over can avoid the manual effort, that's fine. Their frustration would likely make them think about it less. You don't, and shouldn't get prompted to do the same thing using the API, either.

[icambron]

That’s not quite it. The solution isn’t to stop them from doing it or warning them more aggressively; it’s to make it genuinely less dangerous. For example, make the stars all come back when you reverse the switch.

Of course that’s a lot harder to do, since it’s a lot more than a UX change. So I’m not really slagging GitHub here. But it’s the right way to attack this problem.

[mynameisvlad]

True "Undo" is, IMO, a pipe dream for all but brand new projects. That will pretty much require you to rearchitect a decent chunk of anything that wasn't built with it explicitly in mind.

In this case, I don't quite understand why stars and forks need to be deleted when switching visibility, since it seems like the two shouldn't be linked. I can star and fork my private repos just fine, so it seems like it was just easier to clear it out than to deal with RBAC at that level.

[whym]

I don't think any fork was deleted. 3.5k forks as of now vs 3.4k forks in January: https://web.archive.org/web/20220129022012/https://github.co...

Many people won't notice some of their stars having disappeared, but many would be surprised to see their forks deleted without their consent, especially those that are not merely a mirror. People can have diverged forks after adding substantial changes without feeding them back to the original for a variety of reasons.

[kevinforrestcon]

Then don't "do" the delete, when the users "do" the delete.

Pretend to do it, actually do it 24 hours later, and if they "undo" the delete within that time frame, just remove it from the delete queue process.

[ncmncm]

Just not deleting them in the first place, or not deleting them until explicitly asked to, would suffice, and would be, ultimately, less code. So, I am not buying the apologetics.

[djur]

It seems to me that services that pretend to delete data but don't actually do it are usually subject to criticism on Hacker News, not praise.

[everforward]

The counterpoint is that tools like that can be abused. Just as a hypothetical, if I have an open source product and do something the community doesn't like, I can make the repo private til the storm blows over so people can't un-star it. The number of people that remember to un-star it a week or two later is going to be a lot less.

I still think you're right, but it's not even as simple as UX and small backend changes. Allowing the repo owner to re-play other peoples' actions comes with complicated policy decisions. GitHub could make it so only support can restore those, but now they're in the awkward position of having to say when it's okay to restore and when it isn't. Still, it may be the best compromise.

[quacker]

> It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future".

It's sort of equally easy to say Github should do X or Y to improve the UX in this (rare?) case without actually knowing the effort or opportunity cost.

Like maybe I'd rather Github figure out how to not have outages so frequently and how to not accidentally give people million+ dollar bills and such.

[mynameisvlad]

> Like maybe I'd rather Github figure out how to not have outages so frequently and how to not accidentally give people million+ dollar bills and such.

I doubt the engineers working on the stability issues or billing have anything to do with UX and vice versa. It's not like there's a singular focus that everyone at the company must prioritize above all else. Multiple people can work on multiple projects and not impact one another at all.

[ncmncm]

On one hand you have millions of users who each are obliged to walk on eggshells.

On the other, you have a few Microsoft hacks who could easily do the right thing on behalf of those millions of users.

[necovek]

I am surprised so many people treat losing stars as "dangerous": I can certainly emphatize with the designer coming up with this pop-up while looking at a sample project with 12 stars.

Considering this project was out of ordinary in having 54k stars (article mentions being in top 80), they should not be surprised that their case is not top of mind.

Sure, it would be nice to highlight the most destructive of actions, but they already had to type out full project path as confirmation.

I do believe it would be better if Github allowed restoring data in the next few days (soft deletes ftw) once they hit this issue themselves in the past.

And Github support should have recognized that this project is a special, out of ordinary project, and afforded it some engineering time to restore everything.

[Conan_Kudo]

> I am surprised so many people treat losing stars as "dangerous": I can certainly emphatize with the designer coming up with this pop-up while looking at a sample project with 12 stars.

Lots and lots of websites and companies use the number of stargazers as a strangely important metric for success, so losing them can be really bad.

[rob74]

But still, I also share the opinion that GitHub's UX for dangerous actions on a repository is currently already best in class, so blaming them for your mistakes is pretty unfair. To make your repo private, you have to:

- click "change visibility" in the "Danger Zone" area of the settings.

- select "make private" with an additional warning shown that you will lose all stars and watchers. Ok, maybe it should mention how many.

- type the name of the repo into a box and then click "I understand, change repo visibility".

And yes, sometimes it is important to expect humans to not make mistakes. For example, at railway crossings. Even if you drove over it 100 times and no train came, the 101th time you may still die if you don't check for a train before crossing.

[MrBlueIncognito]

> And yes, sometimes it is important to expect humans to not make mistakes. For example, at railway crossings. Even if you drove over it 100 times and no train came, the 101th time you may still die if you don't check for a train before crossing.

For somebody going through a railway crossing, yes, they shouldn't allow themselves to be prone any mistakes there. However, for the people involved in the construction of the railway crossing, they should certainly expect everyone to screw up and scrutinize the safety. We don't want to leave anything affecting livelihoods to chance.

"On average, each year around 400 people in the European Union and over 300 in the United States are killed in level crossing accidents."

https://en.wikipedia.org/wiki/Level_crossing#Safety

[dskloet]

That's why a level crossing has a barrier that's only there when a train is approaching. Imagine the barrier was always there; that would be asking for people to ignore it.

[react_burger38]

This idea - fixing systems that amplify mistakes into large, irreversible impacts-- is why I am against alcohol, marijuana and other mental-state altering drugs for recreational purposes. (I'm not talking about people who really need pain relief from cancer, amphetamines for ADHD, etc.)

If no one in the world drank, smoked pot, or did drugs, how much better off would we all be? 100,000 deaths come from alcohol use every year in the United States alone[1]. That doesn't even account for countless cases of abuse, broken families, crime, and other negative effects of alcohol and drugs.

So many people say "oh well it's fine if I do it, I'm responsible" but then at some point someone isn't fine and isn't as responsible as they think they are.

[1] https://www.cdc.gov/alcohol/features/excessive-alcohol-death....

[dns_snek]

> If no one in the world drank, smoked pot, or did drugs, how much better off would we all be?

Perhaps that's true for your definition of "better off", which is perfectly fine, but it isn't universal. Even though I don't do drugs, I don't think it should be anyone's business to police what other people do with their minds and their bodies on their own time, as long as they don't pose a threat to anyone else.

[wpietri]

You haven't really thought this through.

One, those substances are fine for a lot of people.

Two, some of those substances are fine for most anybody. I've never even heard of a deadly marijuana overdose, and the evidence shows no increase in mortality for marijuana users.

Three, we already tried alcohol prohibition, and we are currently trying drug prohibition. It does not solve he problem you care about, while creating other large problems.

So really, you sound like somebody who has a personal hobbyhorse and uses pretty much anything (like say, losing stars on GitHub or mentioning a book on airplane safety investigations) to argue for it. And that sort of motivated reasoning around argument for societal change strikes me as way more dangerous than somebody eating a THC edible.

[tdfx]

I'm scared to see what your sanitized world would look like. Some of the most interesting art, music, and personal perspective has come from the consumption of the substances you deride as unnecessary and destructive.

[axiomsEnd]

How much art, science and deep, personal perspectives were lost due to abuse and death stemming from substance abuse? In case of certain substances (like alcohol) we have rather hard statistics about it's overal impact on physical and mental condition of society. Slow change from alcohol to safer alternatives (ex. cannabis) is probably one of the best trends in current times.

[headsoup]

How many lives were saved or changed for the 'better' through the escape of, enjoyment of or numbing with drugs and alcohol? Who knows?

Perhaps if we think more like adults instead of infants we can try to understand complex issues better instead of reinforcing black and white stereotypes of the world or rehashing whatever our favourite source of ignorance tells us.

[ufmace]

I think that do-gooders who have a "Great New Idea" for how to make society better are 1000x more dangerous than any type of drug ever invented. People drunk on alcohol mostly fall asleep harmlessly. People drunk on power and how awesome their own ideas are launch prison-industrial complexes, dystopian enforcement schemes, wars, genocides, etc.

It may be an even worse drug. People on drugs mostly have some awareness that their ideas aren't very good. But for those drunk on power, the fact that their same great idea has already been tried and led to total disaster is no cause for concern at all. You see, they're obviously smarter and better than the last batch of power-addicts who tried that, so they'll do it right this time. Heaven help us if we ever discovered a chemical intoxicant that was capable of making people that deluded.

[naedish]

An interesting thought experiment - how many of us would be here at all if not for alcohol? Ignoring butterfly effect aspects, the number of people who were only conceived due to decisions made under the influence of drugs would surely be very large even today, let alone prior to the availability of birth control.

[iforgotpassword]

So, displaying an additional or more explicit warning that mentions stars and watchers makes sense. No arguing, hope they do that. But to me also, it left a little bit of a bad aftertaste that the author completely skips over the part of that process where you have to enter the repository name right where they show the two screenshots side by side.

Anecdotal: You have to enter the full name for a couple destructive actions on GitHub, and every time I had to do it was so jarring to me that I stopped everything, rechecked what I'm doing twice, started wondering if I might be dreaming, am on drugs or a voice in my head is telling me to do something dumb. Like, yes we should improve nonetheless, and I usually try to put myself into other people's shoes before judging them, but this is just one of the few times where I just can't help but, you know, think it was somewhat dumb to make this mistake with the current system in place. Like, next time we have this stars and watchers warning in place and still someone will manage to proceed on autopilot, what do we do next? Have a siren sound go off in addition? Have the user enable their mic and spell out the repo name? Send a written letter to GitHub? You'll never get the error rate to 0, at which point would you rather accept people making mistakes and calling them out on it than adding more inconvenience on top that just bothers everybody else?

[bspammer]

Most people in this thread seem to be ignoring another very major cause: the inconsistent naming for personal READMEs between users and organizations. Users have their README at username/username, but orgs have it at orgname/.github

Nothing else on GitHub is like this: orgs and users are treated as the same class of entity pretty much all the time. I could easily see myself making the same mistake on autopilot.

[_asummers]

They have a bunch of differences under the hood, particularly when you want to give perms. It makes sense, sort of, on its face, that a user can’t have teams, but why? That decision is pretty arbitrary, to me. Then in GHE, users and orgs have all sorts of fun differences when you consider things like internal/public/private and how people can interact with them; to wit, if you’re in ANY team you can see ANY internal repo in an org, but if you’re limited to just personal repos, you can see no such things.

[cmeacham98]

> My view is that expecting humans to stop making mistakes is much less effective than fixing the systems that amplify those mistakes into large, irreversible impacts.

This is applicable to almost any activity: "Sure he was driving drunk, but the car's manufacturer should have prevented that from causing any damage!" I agree that GitHub should improve the design here - privating a '10 star / 1 week old' repo shouldn't be treated the same as privating a '50k star / 10 year old' repo. I don't mean to diminish the fact that GitHub's UI should be improved here.

But the author needs to take some responsibility and realize they were ""driving distracted"", and not act like GitHub is 100% at fault here. Just because GitHub didn't act perfectly doesn't mean the author didn't make any mistakes.

[barrkel]

Neither the author, nor anybody that I can see here, is saying that the author didn't make any mistakes.

But what you are saying is that marginal effort to prevent mistakes is not worthwhile.

Cars, to take your example, would not be as safe as they are today if they followed the principles you've shown in this post and the grandparent. And yes, even when driving drunk, which is illegal, is safer too - stay in lane, adaptive cruise control, automatic braking, etc. have all incrementally made even extremely ill-advised behaviours safer.

[xupybd]

Yeah, it's a different story when dealing with safety.

With industrial machines you have to assume people will do the dumbest thing possible. Because someone will find a way to get crushed in a moving part if they can.

You have safety fence after safety fence and regularly test that your lockouts work.

If you don't do all of this and someone dies you can face very harsh legal penalties.

We don't do this with software when the cost of failure is so much lower but we should still understand smart humans will make mistakes.

[jeffreygoesto]

In software often the cost is paid by other people (your users) and you don't (want to) see them. How much did the Atlassian outage cost it's clients altogether? How much thereof will they need to compensate?

[krick]

Is that book still worth to spend time reading if I do understand what you are saying and I hold the same views? I'm always hungry to learn something useful from books, but more often than not I find these hyped books ("The Checklist Manifesto" comes to mind) really annoying in that they make me spend a significant amount of time reading stupid "curious life stories" to bring across a point that can be expressed in a 3 word sentence, like "checklists are good". And it's even worse when these are trivial truths most sane people would agree on, which doesn't make the "advice" more actionable, because it's just much easier said than done.

I mean, it would be disappointing to read it to find it summarizes exactly to what you just said.

[wpietri]

It's an incredibly rich book. I learned a ton from it. Indeed, I avoided summarizing it here precisely because it's hard to sum up.

[WalterBright]

My favorite is "let's imprison people who make mistakes". It doesn't stop mistakes, it just covers them up.

[db_admin]

People are imprisoned when they are a danger to others or at risk of flight. Their time in prison is meant to reform them and help them back into society. The community is protected from further "mistakes" from a person, while allowing the person to learn not to make the same mistake again.

At least that is the idea.

[ric2b]

Some mistakes are accidents, some mistakes are made on purpose.

The latter needs some kind of consequence in place to offset the benefits from purposefully making said mistakes.

[np_tedious]

From the product's perspective speaking in aggregate, that is entirely correct.

From an individual user's perspective, you still need own your shit and avoid making these mistakes. You can't rely on everything you use having smart safeguards.

There will always be dumb/careless users that a product should consider. There will always be suboptimal UI (we could've just as easily been talking about CLI database tools) that a user should watch out for

[josephjang]

It's not about whether human can make a mistake or not. It's about how much effort should be made to prevent a certain type of human mistakes.

If every system we're interacting daily should be fool-proof, it will requires enormous time and effort. Naturally, we invests more time and effort when it's about life and death situation. If we only lose 2 cents by our mistake, we just don't care.

Of course, I'd like to have more fool-proof design in all the destructive interactions from all websites. But, the question is, does it worth it?

[jonahx]

There is also an audiobook version, for some reason not linked from there:

https://www.amazon.com/Field-Guide-Understanding-Human-Error...

[MichaelBurge]

The penalty for sin is death.

[dheera]

What about cos?

[pbhjpbhj]

death + π/2

[JackFr]

Romans 6:23

The wages of sin is death.

[rhtgrg]

> I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website".

I don't know. Github employees themselves have made this mistake as outlined in the post, and they were easily able to recover from it, which probably lowered the priority on changing any UX.

Essentially, it's a complete non-issue depending on whether Github cares about you.

Would you like the police in your area to behave in this manner? I think not.

[input_sh]

I found GitHub's Senior Director of DevRel on Twitter saying this:

> Sadly we can't easily do that without triggering lots of issue. We tried with a couple of projects in the past and found it caused a bunch of bad things to happen.

https://twitter.com/martinwoodward/status/149333028949351629...

[jacobsenscott]

Idk about "easily", but I'm sure they were motivated. If you've ever tried to restore parts of a database in a piecemeal fashion, it is usually fairly labor intensive. But you would hope there are a few gh engineers who would be motivated to do so without manager approval in the dead of night because httpie is great.

[swiftcoder]

> But you would hope there are a few gh engineers who would be motivated to do so without manager approval in the dead of night because httpie is great

On the other hand, you should really, really, really hope that GitHub has internal guardrails to prevent their engineers making cowboy edits to the production databases without manager approval.

[jacobsenscott]

Haven't worked there, but I assume one engineer just needs one other engineer to approve their PR. I would be pretty surprised if it was more robust that that.

[swiftcoder]

I haven't worked at GitHub either, but I did work at AWS, where a change to a production database required filing a detailed CM (change management form) with step-by-step details of the operations to be completed + monitoring criteria + rollback plans. That CM had to be approved by the senior eng staff of all affected teams, plus the full management chain, and in a high-profile issue like this, the PR/comms teams as well.

[bandyaboot]

> Essentially, it's a complete non-issue depending on whether Github cares about you. Would you like the police in your area to behave in this manner? I think not.

Obviously it would be nice to see A similar response from GitHub regardless of whether the issue at hand is affecting themselves versus a member of their community. But, as long as humans are making the decisions, that’s probably a pipe dream. And honestly, policing could very well be the standard example of this.

[js2]

> I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website".

First of all, this is self-evident. But second of all and more importantly: it doesn’t scale.

The reason we have blame-free postmortems is because people will always make mistakes, so we find ways to change process or design to minimize those mistakes.

If you think you’ll never do something on autopilot, you’re fooling yourself.

[ahepp]

It’s not a “blame free postmortem” though. The author is blaming GitHub for not sending him a handwritten letter from the CEO inviting him not to do the stupid thing he positively affirmed he wanted to do.

The author also neglects to mention he had to type the full project name into a dialog box, which would be critical to any real postmortem. If typing the repo name into GitHub didn’t wake him up, why should we believe listing the number of stars would? The author said he thought he was in a different repo, but that makes no sense.

The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee.

That’s a lot more reasonable than GitHub spending time to implement yet another warning box feature that the author has proved they can ignore regardless of how obvious GitHub makes it.

[js2]

The author is blaming GitHub for not sending him a handwritten letter from the CEO inviting him not to do the stupid thing he positively affirmed he wanted to do.

Please, quote from the article where you read this. I don't see it.

In the article I read, the author admits fault:

> I accidentally made the project’s repository private for a moment.

The author goes on to explain how they made the mistake.

> What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private.

> GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. In this context, and since I just wanted to repeat the same benign action on our organization’s profile, my brain switched to auto-pilot mode.

> I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.

> That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake.

The author does not attempt to hide or misrepresent the GitHub UI that requires confirmation. They show it for both "httpie/httpie" and "httpie/.github".

It does not matter that you have to type the repo name, because once you are on auto-pilot, you proceed past this step. In fact, the author doesn't admit it, but if he's like me, I'll bet they copy/pasted the name. Because the name alone is not sufficient.

The author then goes on to suggest what might have kicked him out of auto-pilot. Providing more information about the repo other than just its name. The name alone is NOT sufficient. And they author shows some example UIs from their own software.

Your suggestion: "The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee."

This simply does not scale. It would require everyone to learn the same lesson for themselves.

I've been a sys admin and developer for over 25 years. People make mistakes. They make them all the time. Putting context-free (or minimal context in the case of the GitHub UI) "Are you sure?" dialogs in front of them does nothing to prevent mistakes.

All the author is asking for is a bit more context from the GitHub UI to help the user realize the significance of their action. This would help future GitHub users to avoid the same error.

[d3nj4l]

Agreed, and I'm genuinely surprised that so many on HN are angry at GitHub when they already made it so hard to do this. The author explicitly mentions they were on autopilot - it would take a significantly more challenging barrier for them to not do the exact same thing no matter how many prompts GitHub put there. It does make sense for it to be more reversible, but I can also understand why GitHub doesn't want to put in the effort: this is a once in a year kind of incident and the resources required wouldn't be worth it compared to signal boosting, like they did on twitter. I, for one, would be extremely pissed if GitHub made it harder for me to do routine actions because there's a possibility of data loss. I signed up for that when I typed the repository name in.

[tyrfing]

I intentionally did this very recently for a whole bunch of old repos (mainly because a Github bot decided to start emailing me weekly about vulnerabilities in stuff that has been untouched for nearly a decade) and was mildly annoyed at how inconvenient it was to make them private. I would have said the warnings are unnecessary overkill.

It's quite amusing to read this so soon after.

[d3nj4l]

Same here - not too long ago I had to take a bunch of repositories private, and while I appreciated the prompt (I've dealt with destructive actions that have even less of a barrier before, and that sucks) it still was annoying to do that again and again.

[taink]

The point the author makes is not that it should be more tedious to make private: they in fact suggest making it as tedious as it is only when you are on a new, non-massively-starred repository. Right now it is only tedious and not sufficiently alarming, is what people are saying.

[alasdair_]

The problem is that this “seemingly obvious advice” is completely useless because it’s not actionable. It’s similar to saying “to avoid the mistake, just don’t make the mistake”

To make a better system for every human, you can either try changing all the humans, or you can change the system that is supposed to serve them. One is easier than the other.

[cycomanic]

I would argue that the fact that GitHub themselves made the same error really tells us that yes the UI makes it way to easy to do this. Considering the number of repos on GitHub I wouldn't be surprised if someone made the same error every a couple of weeks (but typically not with such high stakes).

I would also say that post does not come across to me as he is only blaming GitHub.

[derefr]

If your whole job is to use power-tools, the fact of using power-tools by itself — scary to some — becomes benign for you. `rm -rf` isn't scary to type if you e.g. write CI scripts intended to run in sandboxes all day. Deleting a repo isn't scary if you delete a lot of pointless repos.

A prompt that pops up to warn you that you're doing something potentially dangerous, when you know that what you're doing is benign, is a prompt that's crying wolf. You'll learn to tune it out.

[prepend]

This is a good point and reminds me a story of many years ago when someone accidentally ran “rm -rf” on an important directory and caused a lot of work.

A well-intentioned PM then thought the fix was to alias rm and add prompts to confirm. They had a whole project to add this alias everywhere.

First it broke existing scripts all over the place. So they fixed them to auto apply the confirmation.

Cut to a few months later and someone rm-rf’d something again, ignoring the prompt (or maybe auto applying it).

So the PM wanted a better message and a second prompt.

People are well intentioned but I’ve seen this path of stupidity that doesn’t solve the problem but is an activity in response to a problem.

[Macha]

Yeah, aliases for "rm" to "rm -i" I find are especially counter productive in this regard, as it conditions people to type rm -f after they get spammed to approve several hundred files while trying to delete a git checkout or node modules too many times.

[_moof]

> make sure you're not on autopilot when taking potentially dangerous actions

When it comes to repetitive or familiar actions, this is physically impossible. If a repeated action is dangerous you cannot use a human interrupting themselves as your only control. It just won't happen.

Overall this is a classic UI design failure. In addition to the "people physically can't take themselves off autopilot" problem, the interface destroys the user's data without providing a way to get it back. It would take relatively little engineering effort to make this reversible.

[ncr100]

I disagree because there is no UI to indicate you're in a special repo. And I blame GH for not considering this "large project maintainer" use-case.

When I administered many VAX / UNIX machines waaay back, the terminals were all configured to be 'special' for the super user. It would have been HORRIFICALLY BAD if any command were executed unknowingly.

GH does -not- distinguish for project sizes, so there is NO SUPPORT for its users in this way. Every feature is to be considered with the same "shotgun severity".

[abnry]

How many years have we had to learn from people using programs to know that people make mistakes. Goodness knows how many people burned themselves using "rm". For that reason alone, "rm" is a bad tool, and should be replaced with something like trash-cli.

[freedomben]

that would break billions of scripts and confuse the hell out of hundreds of thousands or millions of users. Especially seems unnecessary since most distros ship an alias that makes the default `rm` command run with the `-I` or `-i` command.

[mynameisvlad]

> Especially seems unnecessary since most distros ship an alias that makes the default `rm` command run with the `-I` or `-i` command.

I would say that makes things even worse. Because it's just training you to rely on -i/I as a sensible default. One day, you'll encounter that one distro that doesn't have that, and it'll be the time where you really wish it were.

[freedomben]

Hmm, interesting point. I removed that alias early personally in favor of giving due respect to rm (especially with a `-r`!), which is probably an indicator in your favor.

[alecbz]

I alias rm to `echo ‘use trash’`, and then use /bin/rm when it’s what I really want.

[abnry]

Of course it is here with us to stay. The point is that if the initial design was different, there would be fewer headaches. We certainly have the power moving forward. And as discussed in the article, a prompt is not enough to deter a user doing something other than what they think they are doing.

[forgotpwd16]

>Especially seems unnecessary

An option that shows a y/n action. That's what GitHub does when you're about to make private/delete a repo (even more asking you to type out its entire name) and yet here we're.

[vaishnavsm]

Sure, I understand that. But I think, as a designer, I can't really control the actions of my users. I can only try to design such that I can get them closer to the action they want to take. From that perspective, I think adding the additional information to the warning UI would, if not solve the problem, at least get us one step closer to helping the user make the right decision.

Tbh, when I've deleted repo's, I've mostly just copied the repo name and pasted it in the box. Careless of me? Definitely. Can GitHub change that carelessness? Probably not. Will a box that says "Stars: 54k" help? I think it'd help me, at the very least.

[saila]

In addition to typing the repo name, maybe they should make you check a box for each type of item that will be deleted:

    [ ] Delete 54,000 stars?
    [ ] Delete 8,000 watchers?
    [ ] etc

[ncmncm]

Or just, you know, not delete anything until otherwise asked to. None of tha has anything essential to do with making the thing private.

[prepend]

Is the repo is private then it’s impossible for anyone to “follow” by starring or watching.

There’s also an issue of taking a repo private, making changes when no one gets alerted, and making it public to make it harder for people to know what’s going on.

[account42]

> There’s also an issue of taking a repo private, making changes when no one gets alerted, and making it public to make it harder for people to know what’s going on.

They could always notify watchers about the repo being made private.

[gpvos]

And, importantly, don't show an item if it has zero items in it.

[oriki]

Yeah, but on the other hand, "don't make mistakes" isn't a meaningful or useful lesson.

[pishpash]

Don't make this specific mistake is a very meaningful and useful lesson.

[alpaca128]

Yes. But without the possibility to undo mistakes you'll stand in ruins before you learned enough lessons.

"Just don't make any mistakes" is the worst stance one can have in this context, it denies reality and only assures you're unprepared when (not if) something important goes wrong.

[wardedVibe]

git clone good

[rmbyrro]

> make sure you're not on autopilot when taking potentially dangerous actions

If they're in autopilot, how are they going to "make sure"?

Everyone has been in this spot several times. Those who didn't are just lucky.

There's got to be external contingencies to protect people when they're in autopilot.

[barrkel]

"The user shouldn't be stupid" - which is what you're saying sounds like to my ears - is not an approach that scales well.

Mistakes happen. It's better to have a really good Undo than a lot of confirmation dialogs.

[mkl]

Having to also type out the number of stars you're deleting when it's above some threshold would probably eliminate the error. I think people who use git a lot are used to having the same or similar repository names in multiple contexts and locations (it's decentralised), so typing out the repository name, even though it includes the user/organisation, is not as severe-seeming as the designers thought. Confirming the consequences seems better than confirming the command.

[prepend]

I think of the burden on the typical use case and think the current prompts should be sufficient.

What’s the star threshold? 1000? 5?

I’d hate to now have to type in the number of watchers and stars as part of the private/delete/move/etc prompt for all the times I know what I’m doing.

It’s a balance between punishing the non-stupid users vs protecting the stupid users. And people switch between these categories. I might be non-stupid today and stupid tomorrow.

[pmontra]

The author explicitly admits "my brain switched to auto-pilot mode." The problem with that is that we're on auto-pilot many times and we realize we're doing it only after something bad happens. The UX should prevent auto-pilot to do harm to us (and possibly to the customer/company relationship.) "You're about to delete 55k stars" should be enough, as the author suggested. But designers can be on auto-pilot too.

[josephjang]

> But designers can be on auto-pilot too. You're blaming some people without any basis.

[lucideer]

> obvious advice: "make sure you're not on autopilot

That... isn't how "autopilot" (or humans in general) work(s).

[Aeolun]

Tbh, it doesn’s look like the wrong repo name if you want to make your organisation README private. I agree with the author that the discrepancy between user and organisation profiles doesn’t help here. If every user/organisation could make a .github repo instead it would be much more obvious.

[mherdeg]

My favorite example of this is that the cloudflare.com web UI has some extremely scary buttons, like a little "bypass CDN" button with a cloud on it that will rapidly increase traffic to your site 2-100x if you accidentally click.

I mean this isn't exactly how it works. But it's a bit scary.

[makeitdouble]

On typing out the name of the resource, it is of course a way better check than just displaying it. I think it also was very efficient when there was only a few places using it, and the novelty made it attention focusing.

Thing is, we type all day, and can type pretty much any string at a decent speed without putting much thought into it.

Any of us must have mistakenly typed a full file path or API URL, just to realize it’s not the right machine or project after having typed it all. It just take 2 or 3s max after all.

I think it becomes an arms race to get attention on important things, we can do better by focusing more on every single destructive operation. We can also avoid having too similar interfaces for completely different contexts.

[oriki]

It's also worth mentioning that the name of the resource here was confusing - the author mentions that this happened because he mixed up how GitHub names profile READMEs for organizations vs users.

[onion2k]

GitHub probably should show the stars in the warning UI

In this particular case the stars would have been a useful clue, but in the majority of similar cases the wouldn't be any stars. It would be a useless and redundant signal.

[sjamaan]

Number of forks, maybe? Or pull requests? Although those wouldn't disappear of course...

[aasasd]

> the author had to _type out_ the name of the repo they wanted deleted

Where does it say that they deleted any repo?

[johnywalks]

> make sure you're not on autopilot when taking potentially dangerous actions

Humans will be humans, we can't help it.

Structures or systems that handle large amounts of user interactions should predict such use cases and design accordingly. a.k.a make them "idiot proof".

[jagged-chisel]

> the author had to _type out_ the name of the repo

I copy/paste the repo name every time I delete a repo on GitHub. Yeah, it’s still a minor impediment, but it’s definitely not “TYPE the account and repo name.”

[tluyben2]

It would be very rare to have lived through an IT career and not make one or two fatal autopilot mistakes. In the 90s and early 00s it was very easy to lose a production system because you did something wrong that you did 1000x times right before. And this is a modern version of it; for me, this should not happen; if I designed GitHub, these people giving stars and watch would get selected based on the visibility of the profile. That hardly costs anything and then the user can just switch between visible and invisible at will and not lose anything. But I have made many similar mistakes in the past which is why I don’t delete stuff usually anymore; I just flag it deleted and gdpr material I encrypt. I simply don’t want either software bugs, hacks or human error to cause any damage. With the cost of storage and the fact that I work only in b2b, this comes at virtually no cost but with a lot of happiness for both our users and myself.

[mro_name]

Yes, and as Don Norman puts it, Design is mostly on how to make errors non-catastrophic. No design nor training ever will abolish them.

Humans err.

[katbyte]

I recommend reading “the design of every day things”, it talks about this exact attitude and why it’s terrible.

[remexre]

Also sudo mode, right? They had to authenticate to the whole website again too, before doing this!

[Abishek_Muthian]

> "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website".

Have the advertisements/sign-up/GDPR pop-ups trained us to 'engage autopilot to dismiss the pop-up' as soon as possible irrespective of its importance?

[pishpash]

Agreed, the swipe at Microsoft (with links he saved from who knows when!) was especially gratuitous. He mad. Don't write something public when bitter should be a lesson right after don't be on autopilot.

[JackFr]

I feel for the guy and what he says about user interfaces is all true, but the tone of the piece grates on me a little.

“I take responsibility, but…” is not “I take responsibility.”

[viscanti]

Data privacy laws like GDPR probably require them to fully hard delete when a user asks for something to be deleted. So any undo functionality would need to make sure it's compliant in every region that could have a privacy law. I'm not sure how realistic it would be to ask companies like Github to jump through all those hoops because people refused to read (and then blindly typed stuff out).

[alpaca128]

I'm pretty sure GDPR doesn't say everything must be wiped instantly but instead within a reasonable time period. One that's certainly enough to undo such actions.

[justinator]

Interesting idea but what PII is stored with stars?

[jdmichal]

I ran into this in pgAdmin recently. When right-clicking on a server, the options to disconnect the server and remove the server are right next to each other. Clicking disconnect presents you with the following dialog box:

"Are you sure you want to disconnect the server? No / Yes"

Click remove presents you with the following dialog box:

"Are you sure you want to remove the server? No / Yes"

Good luck! I mean, it's not a super huge deal to recreate the server entry, but still annoying when you're in the middle of something and just realized what you did.

Honestly, just replacing the "Yes" button with the action being taken would be enough to improve this. "No / Disconnect" and "No / Remove". But my personal opinion is that disconnecting is not a destructive action unless there's an open transaction or running query. So the dialog box should be contextual on that scenario, and otherwise it should just disconnect.

"Disconnecting will cancel executing queries and rollback open transactions. Continue? No / Disconnect"

[JJMcJ]

> just replacing the "Yes" button

Or the lazy web dialog popup with "Cancel" and "OK".

So you click on "Cancel Glorping The Frobnitz" and up pops a dialog with "Cancel" and "OK". It always takes a moments thought does the "Cancel" on the popup mean cancel the cancel glorping or cancel the cancel.

Since it takes literally seconds to change the button captions it might be nice to think of something clearer. Seconds if you're a UI expert which I'm not. Of course the webdev part of changing the captions on the page really would be seconds for me to do.

[JJMcJ]

> mean cancel the cancel glorping or cancel the cancel.

Typing error, it should be

> mean cancel the glorping or cancel the cancel.

[david_allison]

Would you consider submitting a patch?

[jdmichal]

Actually, I should. The biggest hold up will probably be translations though, unless they have that already translated.

[mherdeg]

> While the author clearly feels bad about the fact that they've lost his community and that GitHub couldn't restore it (which is honestly what any of us would've felt under similar circumstances), they're also focusing towards the future and using their personal experience as a parable all of us can learn from.

Also, writing a solid blog post about a customer-service corner case and getting it to the top of news.ycombinator can be a great, if somewhat last-ditch, opportunity to escalate a problem.

[benjaminjackman]

For Lesson 1: I think the general pattern that ought to be followed is to "prefer undo to warnings." Undo is often harder to implement, however it's usually a superior experience.

[vaishnavsm]

I agree that undos are pretty nice for when errors are possible, but I think there's a really good reason to put up warnings too. Let's say they accidentally made the repo private, but didn't notice it (unlike what happened here). Although you would be able to undo the change, it may have only kicked in once the news spread around (followed by reputation damage, etc). A well worded warning would prevent that.

In a way, I think warnings and undo serve two different functions-warnings are meant to inform the user of their action, and undos are meant to roll back actions taken.

[lolinder]

There are definitely still cases where warnings are important, but the point of "prefer undo to warnings" is to eliminate as many warnings as possible to avoid desensitizing users. I should only see a scary pop-up if the action that I'm performing is going to be well and truly destructive.

Undo-instead-of-warning is a great pattern for lower-stakes actions that are easy to undo and cause minimal damage if left done. This allows the few warnings you do show to be recognized as truly important.

[ncmncm]

Even better, flipping "public/private" has absolutely no need to delete any information at all.

There could be separate buttons, "Delete all my stars", "Delete all my watches".

[hk__2]

> Even better, flipping "public/private" has absolutely no need to delete any information at all.

Of course it does. You can’t watch/star a private repo unless you have access, so all watchers/starrers should be removed. If you kept the data as-is watchers would still see the repo updates in their feed, which is the opposite of the 'private' feature promise.

[alpaca128]

Sure, if you don't change any part of the system it has to be that way. But there's no reason a private switch can't just suspend stars/watchers instead of permanently deleting them.

[SnowHill9902]

Rollbacks even better.

[metaltyphoon]

> I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic?

Perhaps the delete action is not accomplished right away and a column is checked. Then after a X amount of months a worker process goes around actually deleting things?

[ncmncm]

There is no need to delete anything at all. Set the "private" flag when the user asks for to make it private. Unset the "private" flag when they make it public again.

If it is needful to be able to delete stars, make a separate button for that. But it is hard to imagine such a need.

[mypalmike]

Stop. You've said the same thing a dozen times in this thread. Besides being repetitive, you're overlooking the obvious fact that having associations from non members of private repos to those repos is problematic. At the very least at the UI level, maintaining known dead internal links is bad form. So you'd be creating edge cases for the UI and probably numerous places deeper in the tech stack as well. Which is fine if you engineer solutions to all the edge cases. Perhaps after this incident they will consider doing so. But it's certainly not as trivial as you imply.

[fer]

Mmh? Maybe it's because I've never touched frontend professionally in my life, but I think that if you're doing it in the UI you're doing it VERY wrong.

This logic should be purely in the DB model or very close to it. In any case the internal API should never ever list private repos of an organization a user isn't a member of, period. Stars or no stars. Follows or no follows. Why should it? There's no corner case here, if stars pose a problem, the problem isn't the stars, it's a defective model behind. Hiding things that aren't meant to be seen in the UI means putting business logic in the UI. Just don't.

[mypalmike]

Fair point. My intent was to point out the UX would be broken. But you're right, the data model that backs that UX is what would have to change.

[brightball]

The complicated thing is that every query has to look for the column.

Ideally, moving the entire serialized record to an archive table keeps things as clean as possible.

[vaishnavsm]

I meant to focus on the cascade part of the equation here. For example, lets say `stars` are foreign keyed (FKed henceforth) to repos, and (say) `X` are FKed to `stars`, and `Y` is FKed to `X`. Then if you do a "hard" delete of the repo status (or the stars), then we can set that to cascade to `X` and `Y` as well. Otoh, I don't think you can apply a cascade like that automatically when you're just changing a value (which is how a soft delete would be implemented, ig). Can you? Is there some really cool hook that allows this?

[sriku]

He did have to type "httpie/httpie" in the box to confirm, no? I'm rather surprised that that didn't snap him out of auto-pilot mode. There ought to have been a DING in the brain seeing that the repo this is being applied to was httpie/httpie?

OTOH, I haven't been in such a mode, so I really got no right to comment on this. Best wishes to the team -- that those who saw his post will restar/rewatch the repo -- and (fwiw) thanks for writing it up and making me even more paranoid (in a positive sense) about doing such destructive operations.

[decafb]

By now I've become so accustomed to just copy the bold text from the line above it and paste, that it doesn't break me out anymore. I know I should concentrate and type it out, but in my head it has just become visual noise and a boring exercise.

[sriku]

Aha .. perhaps the interface can be changed to prevent copy-paste into that field.

[account42]

Better would be to not show the repo name directly above the dialog at all so the user actually has to think a bit about what they need to enter. Just re-typing a text shown to you can be done on autopilot as well.

[ignoramous]

All the talk about auto-pilot mode reminds me of this excellent talk on activation energy, waking up yourself from slumber, or flip-flopping between auto-pilot and emergency modes: Mel Robbins, How to stop screwing yourself over, https://www.youtube-nocookie.com/embed/Lp7E973zozc

[bokwoon]

> I assume that the cascading done on GitHub would be done on a FK constraint

GitHub doesn’t use foreign keys, the cascade delete must have been manually implemented.

https://news.ycombinator.com/item?id=21486494

[ncmncm]

That it took a half hour to do all the pointless activity says something.

[ric2b]

They use Rails, right? It's probably a cascade delete but done on the application, Rails makes that very easy.

[berkes]

Github is built with MVC. On rails no less. Where problems like soft delete are hard, or even impossible to solve (in scale).

Yet there are many architectures beside MVC. Many of them decades old. Proven. Established. Yet unknown to devs who picked up a rails book on day 1 and never looked back (I've been guilty of that for years).

This particular problem is a textbook candidate for Command Pattern. The problem of undo is solved naturally in any event-sourced setup (git is even sourced, and moving through history a prime feature). Probably more architectures that I'm less familiar with, solve 'undo' as well.

But we are stuck with the web, backends in 2022, being built on MVC frameworks like Rails, where solving such issues is tough and complex. So we are stuck with a huge amount of warning dialogs to 'solve' this.

Point being: choose your architecture well, based on your needs and the tradeoffs. Don't just grab the next fancy framework, because that will decide for you, if, and how you solve things like 'soft delete' or 'undo'.

[agraddy]

I'm in the process of creating an MVC framework and was curious about the other architectures you mentioned.

This comment seems to be down on MVC and Rails so I was curious about the alternatives you mentioned and came across your post that ended with praise of Rails ( https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ ):

> Rails still is a great way to get a prototype demo, or minimum viable product online in days with least surprises.

Your comment seems to indicate that you started discovering new architectures like the Command Pattern but it sounds like you are also still a proponent of Rails and MVC based on your blog post. Do you have any links to resources that helped you discover other patterns or could you share what took you on your journey?

In the Rails blog post, you said:

> I have a separate post planned on "RAD web frameworks", MVC and ActiveRecord, but it is safe to say that such frameworks, amongst which Rails, have found their niche, yet are by no means a silver bullet.

Is that post you are planning to write going to delve into some of the architectures you mentioned here? That would definitely be something I would be interested in reading.

[berkes]

I'd suggest going through all Uncle Bob Martin[1]s talks on clean code.

He has a great article (2014), old, on why you may not want to build that framework at all[2] too:

> Using a framework requires a significant commitment. By accepting the framework into your code, you surrender your control over the details that the framework manages. [...] > And yet despite the huge commitment you’ve made to the framework, the framework has made no reciprocal commitment to you at all. That framework is free to evolve in any direction that pleases its author.

Another great source are the books, and/or youtube channel by Dave Farley[3]

What set me on a journey is -decades ago- the pain I, as a developer felt when developing web-applications for my clients. But worse: the pain they felt for getting delivered crap. "Why am I delivering crap" was the question that set me to research frameworks, languages, design patterns and architecture. Drupal, Rails, Django, ASP: I've worked with it, and delivered crap with it.

In general, I found that a framework matters. e.g. the simple act of reading ActiveRecord Critisism on wikipedia[4] got me thingking:

> also due to the strong coupling of database interaction and application logic,

This was true for project D, G and Y! This was why we failed to iterate at any speed at all. Because I can relate it immediate to Real And Actual Problems, Failed Projects, Slipped Deadlines, Burned out colleagues, and so on, all of wich I encountered during my career. Not saying all those problems were caused by ActiveRecord or Rails! But that they were caused by the choice for the wrong framework. Or the choice for a framework at all.

It led me to DDD[5], which then is the gateway into all sorts of Enterprise Patterns. I dislike that name, because the connotation is all wrong. Especially the subtitle of the canonical book on DDD struck a note:

> Tackling Complexity in the Heart of Software

This! This is why I'm delivering crap: I fail to tackle the complexity that inherit in any domain. In e.g. Rails, I would just spread it all over the place, fighting against ActiveRecord and Rails, yet still failing to isolate, modularize and capture that domain.

So I no longer use Rails, nor any framework in my startup. I occasionally do some freelance gigs, often Rails. And the more I learned how to Tackle Complexity in the Heart of Software through choices and tradeoffs, the more I see why a project in Rails that I'm flewn in to salvage, is doomed. It's the choice for Rails. Not lacking of services, not "Fat Models", not "missing tests" nor missing of any sort of "rigorous refactoring" Its Rails! Rails is just unfit for this domain, this problem, this customer.

Yet Rails shines for others: I restate: It's brilliant for simple CRUD. But anything you expect to have any sort of "Complexity in the heart" is probably unfit.

[1] https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g

[2] https://blog.cleancoder.com/uncle-bob/2014/05/11/FrameworkBo...

[3] https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g (his books are promoted on this channel)

[4] https://en.wikipedia.org/wiki/Active_record_pattern#Criticis...

[5] https://martinfowler.com/bliki/DomainDrivenDesign.html

[agraddy]

Thanks for the detailed breakdown! This is really helpful and exactly the kind of information I was hoping you would share.

[realusername]

I don't see why you are thinking it's hard with rails, you just create a default scope in your model "not_deleted", and that's done.

It will apply to all queries unless you specifically call " unscoped"

[h3mb3]

1. Why would it be particularly difficult for them to have soft deletes in Rails or at scale?

2. Like the article suggests, additional UX improvements could be made besides making it possible to restore a backup or providing an undo action.

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.

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.

[berkes]

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

[Aeolun]

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

[legedemon]

https://github.com/rubysherpas/paranoia is enough to solve problems at very large scales.

There is nothing about Rails or MVC preventing someone from doing this. This is a very common design principle for all kind of ERP and BPM systems: don't ever delete anything.

[berkes]

First: soft-delete really doesn't need a library. Paranoia is nice, but almost all of the code and complexity in that gem is to support multiple versions of rails and to let you configure that gem.

DIY in this case really is very simple. And far more flexible, performant even, and future-proof.

(I've worked on a project where two full-time devs spent days upgrading this gem; this is over 6 years ago). And a few months ago, I worked on a project where they had more code to configure, patch and work around paranoia, than any DIY ever did. My even simpler DIY version not only used 50% of the code we had to override the gem before, it allowed for some custom work that we could not do before.

And no: even DIY ain't as simple as you make it seem. Practical issue, that I encountered last year even, was where their "soft delete" was making state-machines very tough. Because in a FSM, "deleted" wants to be state, like anything else. But the "generic soft-delete" conflicts with that. So the project had both. And some fugly glue-code to sync between the FSM and the soft-delete and vice-versa. No suprise that this broke occasionally, making data re-available that people thought gone.

[zach_garwood]

> I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic?

I'm not at a terminal, so I can't check it out, but could you make a compound foreign key with the soft delete column and use the on update cascade? Something like `alter table stars add foreign key (repo_id, is_deleted) references repos (id, is_deleted) on update cascade;`

[ncmncm]

> "that GitHub couldn't restore it"

What an odd turn of phrase.

[vaishnavsm]

Not sure what you meant? Are you pointing out couldn't vs didn't? If so, I didn't really think about it, although now that you point it out, I think didn't would've been a better fit. I'll edit it, thanks!

[ncmncm]

I mean "refused to". There was absolutely no value to Microsoft in refusing to restore the deleted information, and there was no practical reason to have deleted it at all. Ultimately, it just amounts to contempt.

[lalopalota]

"I screwed up. By the way, it's your fault. I hope you realize how many people think more highly of your service because my project is there. Why wont you accept some money for a service you don't provide?"

What's the value in capitulating to that? Also, a user saying "delete this stuff" is a pretty practical reason to do so.

Indifference != contempt.

[ncmncm]

Define the difference.

[a-dub]

or maybe just incompetence? or just retro-1990s microsoft? what is this? slashdot in 1998?

i mean, this is the company that perfected the "throw it all away and start over" serviceability paradigm and the "we don't know what's wrong with it just reboot it every six hours" reliability paradigm for systems.

totally reliable business partner to trust for outsourcing critical business and government infrastructure for sure!

those who are serious and prudent seek assurance, for the reckless and feckless, there's azurance.

if the blog post doesn't work, i'd suggest renaming the project (specifically the cli) such that it makes reference to the hollowness of the new microsoft's apparent love for open source. that way when those thousands of developers (who happen the be of the exact variety that the dinosaur is trying to court) are invoking it every day, it can burn into their skulls to never ever work for, or choose technologies made by, microsoft.

score 5: funny, insightful

[411111111111111]

> I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic?

Couldn't you just use an on delete trigger for this? I have no experience one the subject however

[nine_k]

An ON UPDATE trigger for the is_deleted column would do.

Some databases also support INSTEAD OF triggers.

[vaishnavsm]

Doesn't ON UPDATE only work for foreign keys? As far as I know, it's used to update the foreign key itself, and not values based on relationships.

[belter]

Your comment missed the main lesson of the post.

GitHub (Microsoft) had a non intuitive UI feature, they themselves were victim of. They restored for their own repo but not for the customer repo...Zero customer focus is the lesson here.

"...In our case, however, they refuse to do that, citing undesirable side effects and the cost of resources. We even offered GitHub financial compensation for any resources required. But, sadly, they declined. They have other priorities than resurrecting the community of one of the oldest and most popular community projects on their platform..."

"...So the answer to the question is, unfortunately, the following: GitHub will restore a repo damaged by making it private. But only if it’s one of their own projects, not a community one.."

[SkyBelow]

>I often think scary popup boxes are enough to get people to think about what they're doing

This would entirely depend upon how often it shows up. The more often it shows up when the scare isn't relevant, the less people will pay attention to it.

>the distractions ("Type this repo's name", etc) just go away

I think it shows that what one types needs to be relevant information. In this case, due to the similarity between when the author would've been asked if they did what they were intending to do and what they typed to do what they actually did, we can judge the prompt isn't enough. If this also asked you to type in the number of git stars you were about to lose, that would've been enough to make author recheck exactly what they were doing.

[ezfe]

Factorio doesn't say "You'll lose unsaved changes" if you close the game immediately after saving, which is super nice.

The number of games that DO ask this question, immediately after saving, is ridiculously high it's so frustrating.

[whack]

> Lesson 2, which was to use soft deletes, is something I have more thoughts about. I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic

Relying on database cascade deletions is very dangerous. Especially since as the application/org grows, it's easy to lose track of all the things that may get cascaded. There's a good chance you'll find yourself having cascade-deleted data that you never intended to have deleted.

Manually implementing logic for "when archiving X, also archive Y and Z" takes more effort, but is a lot safer. When it comes to data.

What surprised me most is that github performs irreversible deletions when someone making a repository private. I would have expected them to just create a "is_deleted" column and set that flag to true. I wonder how much of this behavior is motivated by GDPR. Ie, complying with it requires completely deleting data when requested by the user, and they decided the most straight forward way to comply with that requirement is to delete the data immediately when requested.

[harg]

Regarding cascading logic with soft deletes; I think the answer is that you don't cascade anything. You basically need to have `deleted_at IS NULL` conditions in your queries to exclude them.

[CodeWriter23]

I’ve adopted a pattern of:

<dialog-text>

If they click ok:

Asking again to be sure you want to destroy masses of data

<dialog-text>

But even that fails if there is a language barrier.

[organsnyder]

> But even that fails if there is a language barrier.

Surely GitHub is localized? (and if not, why the hell not?)

[sparqlittlestar]

I recall that GitHub used to be localised in several languages, but no more. And I can’t seem to find any references to it anymore, either. “GitHub interface translation” gives search results about code, not about GitHub’s interface