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

71–80 of 214 posts

Re: Yagni Exceptions (2021)

#71

Post by healsjnr1 »

mattclarkdotnet wrote: post #61

I have to disagree with the first point in the article. The “zero, one, many” rule, or the related “rule of three” isn’t about how many items you have in your list, it’s about code reuse. The conclusion is correct though, that you should default to one:many relationships unless you know they are strictly one:one

I don't know that I completely follow on this comment, in particular how code reuse comes into it.

I think the biggest thing is about deciding whether you have one or many.

There are a lot of cases where having many doesn't just mean there is a list to show.

In a lot of cases, having many means you now need to choose "the right one" to show/edit/action whatever.

This brings up all sorts of complications beyond "just return a list instead of a single item".

Even if you don't end up building it out, I think it always a good thought experiment during the design phase to think about how things would behave if there where multiple of key resources, rather than just one.

Would it have implications elsewhere? Are there low cost alterations to the design that can be made now that make space / allow for this key resources to be a list later on? How hard would it these be to do later?

I'm many cases the conclusion might be it isn't worth it and that's the right choice (yagni applied judiciously), but every now and again this might highlight a valuable early stage change that would have cost a lot to make later on.

Re: Yagni Exceptions (2021)

#72

Post by goto11 »

valenterry wrote: post #68
bazoom42 wrote: post #58

Earlier quoted context omitted.

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 .

Exactly. Better imo: Don't use strings but a proper datastructure/wrapper. Later, if you want to add i18n, then change `Wrapper("Hello, welcome to the future")` into `Wrapper("Hello, welcome to the future", "welcome-user")` and just look for all wrappers to find all places. Benefits: it's easy to find the code with a simple ctrl+f from the English version of the site and you don't have any disadvantage except for hav…

This is still not YAGNI enough for me. Why introduce a wrapper you don't need?

The thinking behind anti-YAGNI "future proofing" seem to be that it is cheaper to change something now than in the future. But I reject this premise. Inserting `Wrapper($string)` is exactly as much work now as in the future, but it will add additional overhead to all development going forward.

Perhaps the wrapper is even less work to introduce in the future, since you can add it with a simple search-replace, instead of inserting it manually every time you type a string.

Re: Yagni Exceptions (2021)

#73

Post by orthoxerox »

motogpjimbo wrote: post #39
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…

This sounds like you're opening yourself up to situations where you have rows in data_journal that have status='Loading' but which have started_loading_at=NULL, in violation of your data model. Your premise is slightly flawed in that your second example isn't actually difficult to write or understand as you claim. However, it could be argued that if the logic for selecting "loading" rows is repeated in multiple place…

Another benefit of having a separate status field is that you can index it easily. You could technically index the timestamps, but it's a lot of busywork for the RDBMS, as the values are all distinct.

Re: Yagni Exceptions (2021)

#74

Post by wruza »

onion2k wrote: post #26
hardware2win wrote: post #24

I will play devil advocate Relational databases add too much time overhead due to building schema or configuring orm for schema Migrations management Building an db model to domain model mapper and maintaining it You waste time thinking about building an db model and focusing on that technical layer which probably eventually affecta the way you model your system Nosql gives you modeling freedom which is handy for arc…

Relational databases add too much time overhead due to building schema or configuring orm for schema That sounds like the same sort of argument as "I'm not going to write tests because they slow me down!"

But that statement is true for some development and business models. No automated testing is like mastrubation - no one wants to admit, but many do it.

https://insights.stackoverflow.com/survey/2019 (search for Unit Tests, #-linking doesn’t work correctly on this site, perhaps because they don’t test it)

Also tap on a Job Satisfaction button to see how it correlates.

Re: Yagni Exceptions (2021)

#75

Post by code_runner »

healsjnr1 wrote: post #71
mattclarkdotnet wrote: post #61

I have to disagree with the first point in the article. The “zero, one, many” rule, or the related “rule of three” isn’t about how many items you have in your list, it’s about code reuse. The conclusion is correct though, that you should default to one:many relationships unless you know they are strictly one:one

I don't know that I completely follow on this comment, in particular how code reuse comes into it. I think the biggest thing is about deciding whether you have one or many. There are a lot of cases where having many doesn't just mean there is a list to show. In a lot of cases, having many means you now need to choose "the right one" to show/edit/action whatever. This brings up all sorts of complications beyond "just…

I took this as “if you need more than one, plan for storing ANYTHING greater 1 or greater”

Meaning that if I need to store specifically 2 addresses per user, don’t force it at the data layer… just make it an easy to swap validation and no literal limits elsewhere

Re: Yagni Exceptions (2021)

#76

Post by gdy »

EdwardDiego wrote: post #22
bazoom42 wrote: post #5

Earlier quoted context omitted.

So what would be an example of a software design principle?

Never write a function called destroyBaghdad(). Instead name it destroyCity and pass the target as a parameter.

Ugh.

Try writing destroyKiev instead and see what happens.

Re: Yagni Exceptions (2021)

#77

Post by galangalalgol »

EdwardDiego wrote: post #41
gpderetta wrote: post #36

Earlier quoted context omitted.

Pragmatism vs Dogmatism. For example DRY vs YAGNI. The first is more dogmatic: refactor everything that can be refactored, while the second is more pragmatic. The refactor is probably not necessary and might turn out not to be necessary. An even more pragmatic rule is the You Aint Gonna Need It Yet.

> Pragmatism vs Dogmatism. For example DRY vs YAGNI. DRY often has exceptions to the "rule"/"principle" too though. And people often blog on these exceptions. And pragmatism and dogmatism aren't a xor, they're just convenient labels for the -X and the +X ends of the axis. (Admittedly, the fact that I've seen more "It's okay to have exceptions to DRY" blog posts than "It's okay to have exceptions to YAGNI" indicates y…

That is because DRY sets a puzzle for us, how to cleanly reuse some code. YAGNI on the other hand, denies us a puzzle. We like puzzles.

Re: Yagni Exceptions (2021)

#78

Post by samatman »

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 the language, "You Aren't Going to Need It" is fine, no need to include the T.

Edit: I was drawing further attention to the actual grammatical distinction between "ain't" and "aren't" by showing that "ain't" conjugates the first person and "aren't" doesn't.

It might help to know that "going to" is usually pronounced "gonna" unless it ends a clause, while "gonna" is more normally realized in speech as "goan".

Even more: if you want to reify a partial hypercorrection, go ahead, I'm a descriptive linguist, say the 't' in often while you're at it.

One of my grandfathers would have said something sounding like "yain go need it", the other "you aren't goin a need it".

The latter I'm sure never said the word "ain't" in his life. Nor would he have ever spelled "going to" as "gonna", no matter what it sounds like when spoken.

Re: Yagni Exceptions (2021)

#79

Post by sonthonax »

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 .

Agreed, lots of things never need to be internationalised. Pretty much everything in institutional finance will never need it.

Re: Yagni Exceptions (2021)

#80

Post by sonthonax »

matsemann wrote: post #60
iLoveOncall wrote: post #52

Earlier quoted context omitted.

I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plu…

You don't need to bake in a complete i18n solution, though. Just create a simple map of keys->strings, and then a function ala getStringForKey(key, language) { return map[key] and then whenever you actually need it, just expand on it. But at least you then have all strings in one place, and a common way of accessing them. (And easy lookup of all places using these strings)

Agreed. I don’t really know what problem these i18n tools solve that this doesn’t.
Post reply on HN