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

111–120 of 214 posts

Re: Yagni Exceptions (2021)

#111

Post by pif »

danwee wrote: post #11

Regarding the point about having a relational database: I was of the same opinion, but recently it has been challenged. We were working on a very simple application and one of the first requirements was: > User should be able to have a list of skills (e.g., Golang, Java, OOP, etc.). Users can be filtered by list of skills as well (e.g., "give me all the users with the skills "Java" and "OOP" but not ".net") So, the n…

> we cannot filter anymore by querying only one table

I'd not want to work in a team where that is actually considered an issue.

Re: Yagni Exceptions (2021)

#112

Post by RickHull »

grey_earthling wrote: post #85
samatman wrote: post #78

This is very nearly off topic, but "Ain't" is the correct conjugation to pair with "Gonna". This form comes from Britain and is preserved in some dialects of American English, but "Aren't Gonna" is a partial hypercorrection; if we want acrolect, we must go all the way to "Aren't Going To". "You gonna be at the thing this weekend?" "Nah man I aren't gonna" wrong For the Commonweath, to whom this is no longer part of t…

“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

Re: Yagni Exceptions (2021)

#113

Post by scott_w »

danwee wrote: post #11

Regarding the point about having a relational database: I was of the same opinion, but recently it has been challenged. We were working on a very simple application and one of the first requirements was: > User should be able to have a list of skills (e.g., Golang, Java, OOP, etc.). Users can be filtered by list of skills as well (e.g., "give me all the users with the skills "Java" and "OOP" but not ".net") So, the n…

Serious question: why is "having an extra table" considered such a challenge? I've seen this in a few places and it always raises alarm bells in my head.

Re: Yagni Exceptions (2021)

#114

Post by galangalalgol »

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…

I agree that we have to be very vigilant against the what ifs, but with the exception of logging, which is the one I most disagree with (unless it is helping you debug a failed test), these all seem like cases where the future thinking thing takes precisely as much time as the ship-it-now thing.

The versioning thing could get really out of hand too probably now that I think about it.

But timestamps, many vs two, and the "uh this is starting to sound like a database, lets use one" are all effort neutral.

Re: Yagni Exceptions (2021)

#115

Post by [deleted] »

enriquto wrote: post #10
dmichulke wrote: post #7

Earlier quoted context omitted.

It's only bad if you read "YAGN Exceptions"

But this would be very good advice! Exceptions (a.k.a. modern-flavored COMEFROM statements[0]) are extremely confusing and have no place in a clean codebase. [0] https://en.wikipedia.org/wiki/COMEFROM

[deleted]

Re: Yagni Exceptions (2021)

#116

Post by brodouevencode »

YAGNI as a whole, I've found, is an oversimplified hammer used to justify bad behavior and cutting corners. The engineers that quickly and happily throw around "YAGNI" have never had to deal with a Sev1 outage whereby you're hemorrhaging money - often because you don't exactly know where your system is failing because you don't exactly have good logging/tracing/observability in place.

EDIT: this is not to say it doesn't have utility. As a guiding thought it most certainly does. But it's also easily abused.

Re: Yagni Exceptions (2021)

#117

Post by galangalalgol »

scott_w wrote: post #109
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…

If adding these things really slows your ability to ship the first version of your product, you need to fire your team and start with a new one. These PAGNIs are: 1. log.info() calls 2. apt-get install postgresql 3. Using timestamp and datetime.now() instead of boolean fields 4. Adding a /v1/ into your API endpoints I'm being serious. If your team says "this will add a week onto the release date" then your team is ei…

If it is just API endpoints, but I can see some junior dev spending time putting version numbers on literally every data structure, taking the exception as a rule.

And when logs go from "huh, if this happens I want to know about" type thoughts as you are coding to "lets make a full pass and see where I could have added some logs to this PR" then effort is being spent too far in advance.

I definitely agree timestamps, two vs many, and don't reinvent the database (or don't assume your db is flat) are effort free and always worth it.

With the caveat that you maybe can't afford the overhead of a full rel db, and have to use something like an ECS for performance reasons. This is pretty common for embedded or game domains.

Re: Yagni Exceptions (2021)

#120

Post by iLoveOncall »

matsemann wrote: post #96
iLoveOncall wrote: post #87

Earlier quoted context omitted.

Your function doesn't solve any of the issues I mentioned, you still need to switch to another file, still need to think of a sufficiently explicit key, still need to handle plurals and masculine / feminine variations, etc.

YAGNI ;) You can skip all those things the first time. You don't need to have a separate file or anything. Just have a stupid function returning its input or whatever. The important part is having an entry-point, and an easy way to find all relevant uses in the future. You could then later, when i18n is needed, write a script finding those usages and automatically extract them. That's what I've done once before. And…

> The important part is having an entry-point, and an easy way to find all relevant uses in the future.

You already have it, it's everything that's in between {{ }} and > </.

Post reply on HN