Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yagni Exceptions (2021)

lukeplant.me.uk

Post reply on HN
Print view View original

151–160 of 214 posts

Re: Yagni Exceptions (2021)

#151

Post by Supermancho »

satyanash wrote: post #2

> I'm essentially a believer in You Aren't Gonna Need It — the principle that you should add features to your software — including generality and abstraction YAGNI is not a principle. It is a contextual thumb rule. A codification of expert intuition. Exceptions to thumb rules are quite the norm. Conflating thumb rules with principles is a sign of sloppy thinking. Often engineers will misuse terminology thinking that…

> This can apply to protocols, APIs, file formats etc. It is good to think about how, for example, a client/server system will detect and respond to different versions ahead of time (i.e. even when there is only one version),

A blogpost/article about YAGNI manages to suggest a rather nuanced feature should always be included, that isn't needed, right up front.

Re: Yagni Exceptions (2021)

#152

Post by dkarl »

jakelazaroff wrote: post #136
dkarl wrote: post #123

Rarely do I read something so specific about software development that I agree with 100%. One thing I would add: soft deletes in relational databases. There's a really good chance that eventually you'll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes. For some types of businesses, I wonder if "right to be forgotten" should be designed in from the beginning a…

Can't agree with you there. I've never seen a situation in which it was necessary to recover "optimistically" soft-deleted data. I have seen multiple situations in which soft-deleted data was accidentally included in live queries.

Not recover, but explain to the users that the data was deleted, and when it was deleted. If you have to provide support to customers, you will get a steady trickle of confused and angry customers wondering why their data disappeared after they (or their coworker, etc.) deleted it. Soft deletes let you answer those inquiries confidently with very little effort. With hard deletes, complaints like that can eat up support time with no satisfactory resolution.

I haven't experienced soft-deleted data being accidentally included, but I think that's because I've worked with systems that included soft deletes from the very start.

Re: Yagni Exceptions (2021)

#153

Post by sicromoft »

dkarl wrote: post #123

Rarely do I read something so specific about software development that I agree with 100%. One thing I would add: soft deletes in relational databases. There's a really good chance that eventually you'll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes. For some types of businesses, I wonder if "right to be forgotten" should be designed in from the beginning a…

Counterpoint: https://brandur.org/soft-deletion

HN discussion: https://news.ycombinator.com/item?id=32156009

Re: Yagni Exceptions (2021)

#154

Post by AnimalMuppet »

marcus_holmes wrote: post #92

YAGNI is about avoiding premature optimisation. A lot of these make sense. But they always do. And the road to shipping hell is paved in good architectural practices. To ship a first version of a product, we always need to cut corners. Deep, horrible, painful, cuts. Because if we spent the time to make the perfect product, we'd launch too late. A lot of these YAGNI things are not "you're never going to need it", but…

YAGNI is about much more than avoiding premature optimization. It's about avoiding premature work, of any kind. Optimization, sure, but also implementation and even design.

I know that design sounds like the kind of work you don't want to avoid. But designing, say, a spiffy database query cache so that you don't hammer the database with repeated queries, before you know that you need such a thing? Don't bother designing it. YAGNI. (I mean, you might go so far as to think "If we need it, we'll put it here". But an actual, detailed, implementable design? No. It's likely to be never needed, and is therefore a waste of your time.)

Re: Yagni Exceptions (2021)

#155

Post by Tyr42 »

dkarl wrote: post #152
jakelazaroff wrote: post #136

Earlier quoted context omitted.

Can't agree with you there. I've never seen a situation in which it was necessary to recover "optimistically" soft-deleted data. I have seen multiple situations in which soft-deleted data was accidentally included in live queries.

Not recover, but explain to the users that the data was deleted, and when it was deleted. If you have to provide support to customers, you will get a steady trickle of confused and angry customers wondering why their data disappeared after they (or their coworker, etc.) deleted it. Soft deletes let you answer those inquiries confidently with very little effort. With hard deletes, complaints like that can eat up suppo…

Perhaps Tombstones would be a better choice, where ether data is deleted, but a record of when and why is included instead?

Re: Yagni Exceptions (2021)

#156

Post by no_wizard »

dkarl wrote: post #123

Rarely do I read something so specific about software development that I agree with 100%. One thing I would add: soft deletes in relational databases. There's a really good chance that eventually you'll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes. For some types of businesses, I wonder if "right to be forgotten" should be designed in from the beginning a…

I'm far more partial to the "deleted" table that simply removes the deleted entries from one table into another.

Slightly more hassle on the recovery side (in the rare event), way less risk on the read side, and covers the 90% use case where most of the time its more useful for things like debugging. Only rarely in my career have I seen soft deleted data get restored, but you don't lose that this way, you simply mitigate against accidentally showing it.

All in all, its a better compromise than soft deletes

EDIT: I'm pretty tempted to just convert this to dumping out to a SQLite 3 database for all soft deletes. I wonder if actual DB separation is better somehow for backup / compliance

Re: Yagni Exceptions (2021)

#157

Post by fernandotakai »

no_wizard wrote: post #156
dkarl wrote: post #123

Rarely do I read something so specific about software development that I agree with 100%. One thing I would add: soft deletes in relational databases. There's a really good chance that eventually you'll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes. For some types of businesses, I wonder if "right to be forgotten" should be designed in from the beginning a…

I'm far more partial to the "deleted" table that simply removes the deleted entries from one table into another. Slightly more hassle on the recovery side (in the rare event), way less risk on the read side, and covers the 90% use case where most of the time its more useful for things like debugging. Only rarely in my career have I seen soft deleted data get restored, but you don't lose that this way, you simply miti…

uh, that's a really interesting idea that i've never used before -- like a graveyard for data.

have you done it before? how did you implement it?

Re: Yagni Exceptions (2021)

#158

Post by [deleted] »

bazoom42 wrote: post #58
matsemann wrote: post #13

* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need internationalization/translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it's requested that these be managed by a cms of some sort instead of hardcoded all over the place.

Sure, but what if you never need to internationalize? Introducing a level of indirection have a cost. This is exactly why YAGNI applies. Refactor the code to support a requirement when the need arises .

[deleted]

Re: Yagni Exceptions (2021)

#159

Post by robertlagrant »

adammarples wrote: post #104
robertlagrant wrote: post #37

Earlier quoted context omitted.

> In MySQL, though, as you said, you have to come up with two tables (one for `user`, one for `skills`, make sure FK are in place, and then use joins for filtering... doesn't seem to me that this model fits better) Their other option was an array-typed column. As per the article, Postgres' JSONB column type will give you that, as one example. But the skills table - and many to many linking table - shines as soon as y…

Additionally, FK constraints are a good thing, they mean that one of your users doesn't have the "Python" skill while another one has the "Pytthon" skill. You need this - and with SQL it's extremely easy to implement.

Are you replying to the comment you mean to be replying to? :)

Re: Yagni Exceptions (2021)

#160

Post by no_wizard »

fernandotakai wrote: post #157
no_wizard wrote: post #156

Earlier quoted context omitted.

I'm far more partial to the "deleted" table that simply removes the deleted entries from one table into another. Slightly more hassle on the recovery side (in the rare event), way less risk on the read side, and covers the 90% use case where most of the time its more useful for things like debugging. Only rarely in my career have I seen soft deleted data get restored, but you don't lose that this way, you simply miti…

uh, that's a really interesting idea that i've never used before -- like a graveyard for data. have you done it before? how did you implement it?

yes, I have done it, and I've implemented it two ways:

A temporary "marked for deletion" (I guess temporary soft_delete) field was used to mark rows for deletion (we had a user trash type deal) anything older than 30 days just got dump into a new table, and it recorded some simple metadata, but the data itself was dumped as JSONB. The important thing is we always recorded a way to figure out the customer / user without having to dig into the JSON blob, so if they ever actually left the platform we could still delete the data in full quite easily. This was key. It preserved the PK system we had in place for stuff like this.

In another, more naive implementation, we just dumped it out into JSON blobs with special "$metadata" fields describing data types, deletion time, and other associated metadata I can't quite recall. if I recall correctly those were then encrypted and stored elsewhere (I can't recall where exactly, but likely S3 or equivalent). I don't think this was a good idea, but its what was done.

Post reply on HN