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

91–100 of 214 posts

Re: Yagni Exceptions (2021)

#91

Post by gpderetta »

jillesvangurp wrote: post #9

YAGNI is not an excuse to take lots of shortcuts against known good implementation patterns. Second guessing years of people doing things right by naively assuming you won't need something is more likely to be a mistake than it is not. Do it properly the first time. Actively creating technical debt against your better judgment is silly.

Abstraction is critical, but it is also very hard.

Unneeded and wrong abstraction creates more technical debt than no abstraction. A simpler design is easier to extend, and worst case rewrite, than a more complex, abstract design.

If you know by experience, personal or otherwise, that a design or abstraction is sound, and you know you are very likely to need it in the future, go for it. Otherwise, YAGNI.

Re: Yagni Exceptions (2021)

#92

Post by marcus_holmes »

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 just "can we ship the first version without it?".

Re: Yagni Exceptions (2021)

#93

Post by nine_k »

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…

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

Re: Yagni Exceptions (2021)

#94

Post by goto11 »

valenterry wrote: post #84
goto11 wrote: post #72

Earlier quoted context omitted.

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 intro…

I don't think so. That's just a semantic description of what you are doing. Call it `UserMessage("....")` or whatever. If you go without that and have simply plaintext for any kind of thing, you might at some point mix up passwords with user messages and stuff like that. Has nothing to do with future-proofing. You need user-messages? Then create user-messages and not strings. You don't need translations? Then don't c…

Lets say I write a HTML page.

   Hello world
Is less work and complexity than:

   {{ UserMessage("Hello world") }}
Introducing this abstraction before it is needed is a waste of resources and opportunity cost. Lets say you have the first solution, and someone decides "world" should be a link. Easy, you insert an -tag. In the second example such a change would be much more complicated. You have suddenly made your work much more difficult for no benefit at all.

Sure, if you discover at some point in the future that you actually need translations, then you have to work through all text and decide which strings need to be translatable. Yes, that is work, but you have done that anyway! There is no extra work. And every text which have been deleted between the abstraction was introduced and the translation became necessary, would have had an extra cost which is wasted anyway.

Re: Yagni Exceptions (2021)

#95

Post by wruza »

zarzavat wrote: post #88
wruza wrote: post #57

Earlier quoted context omitted.

that have status='Loading' but which have started_loading_at=NULL, in violation of your data model Why not CHECK() it then? Or make ‘status’ GENERATED STORED or do a similar thing on triggers. The way that you suggested is also good, but it creates two names, one for update, another for select, which may confuse orms or developers.

The iron law of data is that there should be one source of truth. It’s always better to enforce constraints statically (in this case by the schema) than dynamically at runtime. Because avoiding inconsistencies is the human’s job, the computer sure as hell won’t know what to do about it.

Not sure I understand a context for this, since checks and triggers are as static as views in a schema sense, and all of them are dynamic in a sense of computation (though get updated at different times).

If you mean that columns/fields should not share parts of the same “fact” even if one of them is computed or both are constrained accordingly, then I disagree.

Re: Yagni Exceptions (2021)

#96

Post by matsemann »

iLoveOncall wrote: post #87
matsemann wrote: post #60

Earlier quoted context omitted.

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)

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 it was a thousand times easier than the time before where we had to hunt through all of frontend, backend, cms etc. to find stuff.

Re: Yagni Exceptions (2021)

#97

Post by malandrew »

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.

I would go further with your idea. You should have all I/O separated and in on place. UI is just a special case of I/O for apps.

In services you also want to keep all RPC handlers in on place (or any interface with which others interact with your binary). You also want to keep any interfaces with which you make IPC calls each separate and in one place as well. I use IPC (inter process communication) as this includes service clients, database clients, disk access, peripheral access, etc as well.

Re: Yagni Exceptions (2021)

#98

Post by [deleted] »

EdwardDiego wrote: post #18
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…

> Conflating thumb rules with principles is a sign of sloppy thinking Multiple dictionaries and thesauruses would disagree with you there. Rule of thumb is often defined in terms of "rules, procedures, principles, or... ...derived from..." Some sources say that "rule of thumb is a principle or procedure..."" So, you know, going straight to "sloppy thinking" reminds me of OldManYellsAtCloud.jpg. Anyway, I'm really not…

[deleted]

Re: Yagni Exceptions (2021)

#99

Post by wruza »

orthoxerox wrote: post #73
motogpjimbo wrote: post #39

Earlier quoted context omitted.

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.

This is orthogonal, because expressions can be indexed too. Of course if you see the same expression three+ times in your code, it’s begging for a name.

Re: Yagni Exceptions (2021)

#100

Post by adammarples »

robertlagrant wrote: post #37
danwee wrote: post #30

Earlier quoted context omitted.

That's what I wrote yes. I could also have achieved the same using the file system and plain files, or using a graph database. My point is/was: the document model seemed to us the model that fit the best for our problem: the `skills` attribute is an unbounded list (well, in practice the list was bounded to have at most 50 items) that can be filtered by. So in MongoDB, that's plain simple to implement. In MySQL, thoug…

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

The data model fits better. The data is relational and fits neatly into a simple relational table of user_id, skill_id. I think perhaps you just don't perhaps like SQL syntax which is why a join feels weird to you, but what you've described is a 4 or 5 line sql query which anyone can understand. Additionally, you can now easily answer questions like. "How many skills does the average user have?" "Who has the most skills?" "What are the most popular skills?" etc, all likewise in trivially simple sql expressions.
Post reply on HN