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

181–190 of 214 posts

Re: Yagni Exceptions (2021)

#181

Post by hinkley »

AnimalMuppet wrote: post #154
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 desi…

> It's about avoiding premature work, of any kind.

It's even worse than that. Features have complexity, and they introduce constraints. Without active effort to fight entropy, each new feature costs a bit more than the last.

Putting what-if delegation in, before the Rule of 3 tells you how to best accomplish it, slows down everyone working in that part of the code, especially new people and folks trying to debug. You can organize code so it's hostile to delegation, or amenable to delegation. It's not free but it's relatively cheap, if your team is on-board. If not you're going to have a lot of teachable moments.

I don't build what-if features into my code much anymore. What I build in instead is potential. If I wanted to change this code, here is where I would do it. But not yet.

Re: Yagni Exceptions (2021)

#182

Post by DenisM »

orthoxerox wrote: post #15

> More generally, instead of a boolean flag, e.g. completed, a nullable timestamp of when the state was entered, completed_at, can be much more useful. In my experience, the timestamps should almost always be entered in addition to the flag. select * from data_journal where status = 'Loading' is much easier to write and understand than select * from data_journal where started_loading_at is not null and finished_loadi…

Not just easier to write but also easier to index and easier for the query engine to optimize the query plan.

Re: Yagni Exceptions (2021)

#183

Post by gfody »

MrZander wrote: post #163
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…

Our current system uses soft deletes, and I wish we had done a "deleted" table. The biggest downside to soft deletes for us is that it ruins the default indexes cause every query has a !IsDeleted where clause added to it.

this works better if you split your whole schema into a physical and logical layer, which is a lot of boilerplate but seems like a pagni as well since physical concerns that shouldn't change logical semantics always eventually creep in. this entails at least a view with instead-of-delete triggers and making all indexes be filtered indexes for all tables so it's a lot of boilerplate.

Re: Yagni Exceptions (2021)

#184

Post by tinco »

dkarl wrote: post #172
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…

Too late to edit my original comment, but I'm surprised not to see more discussion about "right to be forgotten." It's legally mandated for some types of data in some jurisdictions, and it's hard to implement in a schema that has evolved without it. It doesn't affect the company I work at now, so I haven't had to think much about it, and I was hoping to hear from people who have.

My company doesn't deal with personal information, so ymmv, but the way we deal with soft deletes is deleting the password, setting their name to "Deleted user" and setting the e-mail address of the user to deleted-@ourdomain. That's all personal information, all other information they produced on our platform is property of the company they work for so it's not their or even our call to make if it should be deleted.

Keeping the user record in the database helps bring complexity down tremendously.

Re: Yagni Exceptions (2021)

#186

Post by yellowapple »

sicromoft wrote: post #153
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

Relatedly, I've worked with systems that would maintain a "deleted" or "archived" table for every normal table, with an identical schema. I nowadays prefer it over a deleted_at field for many of the same reasons as the article.

I also nowadays don't care much for created_at or updated_at; IMO it's preferable to maintain an actual transaction log (which is something I'd add to the YPGNI list, given how invaluable that tends to be for auditing purposes).

Re: Yagni Exceptions (2021)

#187

Post by wizofaus »

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…

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

Or you could use a system versioned temporal table (or the equivalent in non-MSSQL databases), then the DB does the work for you, and allows recovery of UPDATEs too. Not sure exactly what the performance implications are.

Re: Yagni Exceptions (2021)

#188

Post by yellowapple »

fknorangesite wrote: post #173
nine_k wrote: post #93

Earlier quoted context omitted.

Shouldn't the "ain't" form require double negation, as in "you ain't gonna need no exceptions"? Then YAGNI would need to be transformed to something like YAGNNOI, "you ain't gonna need none of it". (An offtopic technicality comment being at the top on HN always amuses me.)

> Shouldn't the "ain't" form require double negation, as in "you ain't gonna need no exceptions"? Only in some dialects.

And in some of those dialects, "no" expands to "none of them there doggone"

Re: Yagni Exceptions (2021)

#189

Post by yellowapple »

RickHull wrote: post #112
grey_earthling wrote: post #85

Earlier quoted context omitted.

“You aren't gonna need it” is ordinary colloquial British English. “I aren't…” is not.

You're not gonna need it I'm not gonna need it You aren't gonna need it I amn't gonna need it You ain't gonna need it I ain't gonna need it

She's not gonna need it

They're not gonna need it

She isn't gonna need it

They aren't gonna need it

She ain't gonna need it

They ain't gonna need it

"Ain't" is wonderfully versatile.

Re: Yagni Exceptions (2021)

#190

Post by worik »

"By this I mean, if you need a database at all, you should jump to having a relational one straight away, and default to a relational schema, even if your earliest set of requirements could be served by a “document database” or some basic flat-file system. Most data is relational by nature, and a non-relational database is a very bad default for almost all applications."

That is terrible advice.

Relational databases are heavy weight solutions, expensive and slow.

Make a data interface from the start, yes. But start with backing with a flat file and exhaustive search. Simple, cheap, and more efficient than relational databases, indexing, sorting, and/or binary searching until you have a lot of (for some definition of "a lot of") data.

Post reply on HN