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

11–20 of 214 posts

Re: Yagni Exceptions (2021)

#11

Post by danwee »

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 non-relation model fits perfectly (so, we ended up using MongoDB and the `skill` attribute of "User" is just an array). I know it's possible to use, let's say, MySQL and build a couple of tables to achieve the same, but it just "didn't feel right" (e.g., we cannot filter anymore by querying only one table... and if that requirement is needed, we would need to build a view. But the view needs to be updated regulary, and it just feels like yet another stone in the road of achieving our requirements. The document model, on the other hand, felt just right)

Re: Yagni Exceptions (2021)

#12

Post by syastrov »

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 performance and maintainability. The APIs and the frontend only supported 2 user messaging still.

And the system never needed multiuser chat.

Re: Yagni Exceptions (2021)

#13

Post by matsemann »

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

Re: Yagni Exceptions (2021)

#15

Post by orthoxerox »

> 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_loading_at is null

Re: Yagni Exceptions (2021)

#16

Post by awestroke »

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…

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

Re: Yagni Exceptions (2021)

#17

Post by number6 »

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…

If you have to answer: "does it usually take so long or is something broken?" The Timestamps would be handy. Oh and you can estimate an average for the execution time; investigate performance degradation or improvements

Re: Yagni Exceptions (2021)

#18

Post by EdwardDiego »

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 sure what difference you perceive - principles are often derived from experience, as well as theory, and they often have exceptions too.

Many people have a principle of not committing violence, for example. _Except_ when (multiple clauses follow).

Re: Yagni Exceptions (2021)

#19

Post by lgreiv »

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…

YMMV but with the introduction of JSON/JSONB columns in Postgres, this becomes very easy to achieve without introducing multiple databases. In my experience, at some point relational data will be required in most projects, even if it was not a requirement in the first iterations. Obviously, constraints may apply that make NoSQL a sensible choice in some scenarios.

Re: Yagni Exceptions (2021)

#20

Post by orthoxerox »

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…

This doesn't look that hard to model relationally:

    select distinct user_id
    from user_skills
    where skill_id in @1
    except
    select user_id
    from user_skills
    where skill_id in @2
The biggest hurdle would probably be the lack of support in your database driver for passing collection-like parameters.
Post reply on HN