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

31–40 of 214 posts

Re: Yagni Exceptions (2021)

#31

Post by forgotmypw17 »

syastrov wrote: post #12

I experienced a case of zero one many that would have been better if YAGNI was applied. We were building a messaging system for a system that was being rewritten, where the only requirement was direct messaging between 2 users. It was suggested to generalize it to support multi-user conversations since that was a product desire some time ago. This complicated the backend implementation significantly, including perfor…

Isn't this, technically, a case of "one", since it's one user messaging one user?

Re: Yagni Exceptions (2021)

#32

Post by awestroke »

danwee wrote: post #30
awestroke wrote: post #16

Earlier quoted context omitted.

Am I missing something, or could you have achieved the same thing with a relational database using joins? Or even an array-typed column?

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…

I interpreted your comment as you claiming a view would have been needed.

The list of things required in a relational database does not seem long to me. I could probably come up with an even longer list for what's required when using Mongo.

Also, my point about an array typed column still stands

Re: Yagni Exceptions (2021)

#33

Post by syastrov »

forgotmypw17 wrote: post #31
syastrov wrote: post #12

I experienced a case of zero one many that would have been better if YAGNI was applied. We were building a messaging system for a system that was being rewritten, where the only requirement was direct messaging between 2 users. It was suggested to generalize it to support multi-user conversations since that was a product desire some time ago. This complicated the backend implementation significantly, including perfor…

Isn't this, technically, a case of "one", since it's one user messaging one user?

Yes, you are right. I was just mentioning the name of the principle as used in the article.

Re: Yagni Exceptions (2021)

#34

Post by twic »

danwee wrote: post #30
awestroke wrote: post #16

Earlier quoted context omitted.

Am I missing something, or could you have achieved the same thing with a relational database using joins? Or even an array-typed column?

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 a docucument database you model this as a document with a field which is an array. In relational database, you model this as two tables.

In both cases, you simply model according to the philosophy of the database. It is incorrect to think either is more "natural" in some intrinsic sense.

Re: Yagni Exceptions (2021)

#35

Post by robertlagrant »

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.

True, although at least on mobile I think this is a button press in the IDE. Maybe Javascript/non-mobile native apps have it harder.

Re: Yagni Exceptions (2021)

#36

Post by gpderetta »

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…

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.

Re: Yagni Exceptions (2021)

#37

Post by robertlagrant »

danwee wrote: post #30
awestroke wrote: post #16

Earlier quoted context omitted.

Am I missing something, or could you have achieved the same thing with a relational database using joins? Or even an array-typed column?

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 you want to treat skills as first-class concepts in some way, e.g. "only let people pick from this list of skills the skills administrator has approved" or "count how many people have the skill 'Java'". Then tables seem much more natural, as the skills table can model them as concepts in their own right.

Re: Yagni Exceptions (2021)

#38

Post by dkdbejwi383 »

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…

Using a relational DB doesn't necessitate the use of an ORM. This is another case of YAGNI. I rarely reach for an ORM until there's significant enough complexity to warrant it, and even then it's not a decision made lightly.

Designing and maintaining a schema is not too arduous. There are tools which can produce a diff between the current and desired schema for your database, for instance Migra for Postgres (https://github.com/djrobstep/migra).

Re: Yagni Exceptions (2021)

#39

Post by motogpjimbo »

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 places then a layer of abstraction over it would be useful. This could be achieved in SQL by e.g.

    CREATE VIEW loading_entries AS
    SELECT * FROM data_journal 
    WHERE started_loading_at IS NOT NULL AND finished_loading_at IS NULL
or, if you have several such statuses you need to define,

    CREATE VIEW data_journal_view AS
    SELECT
    data_journal.*,
    CASE
      WHEN started_loading_at IS NOT NULL AND 
    finished_loading_at IS NULL THEN 'Loading'
      WHEN ... THEN ...
      ELSE 'Some other status'
    END AS status
    FROM data_journal

Re: Yagni Exceptions (2021)

#40

Post by mikro2nd »

toolslive wrote: post #25
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…

Off topic, but I think skills are not a binary thing. They have levels. Also skills might be transferable: fe programming languages, if you know language X, language Y is just a small step away (not talking about the eco-system here), and skills might be dependent: (How can you have the skill "java" and not have some level of "OOP" ?) I have yet to see an ontology that fits reality here :(

Oh!... Having "Java" but no clue of "OOP"? Seen it any number of times. Devs who've migrated from a C or Cobol background with little/no/hopelessly inadequate OO training in particular. The code is predictably horrible.
Post reply on HN