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

41–50 of 214 posts

Re: Yagni Exceptions (2021)

#41

Post by EdwardDiego »

gpderetta wrote: post #36
EdwardDiego wrote: post #18

Earlier quoted context omitted.

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

> 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 you're right about their relative weighting on that axis.)

Re: Yagni Exceptions (2021)

#43

Post by hardware2win »

dkdbejwi383 wrote: post #38
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:/…

I didnt say it is

I said building schema or configuring an orm which will create schema.

Re: Yagni Exceptions (2021)

#44

Post by hardware2win »

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!"

Even if it sounds, then what?

Are you trying to say that NoSQL based systems are less reliable?

Re: Yagni Exceptions (2021)

#45

Post by techdragon »

dkdbejwi383 wrote: post #38
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:/…

Yet more counterpoints, I find that more often than not, as a project matures the more it ends up implementing its own half baked ORM internally and much time will often be saved just using an ORM from the start. It’s harder to restructure all your data to fit the ORM you eventually need to manage X developers working on the application than it is to just pick and use an ORM from the start.

Re: Yagni Exceptions (2021)

#46

Post by onion2k »

hardware2win wrote: post #44
onion2k wrote: post #26

Earlier quoted context omitted.

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!"

Even if it sounds, then what? Are you trying to say that NoSQL based systems are less reliable?

Nope. I'm saying that if your argument is "I'm choosing this tech because I'm slow at this other tech" then it's very likely you're making a poor choice. There's nothing inherently slow about designing a relational database. The work required takes time, but the same is true if you're designing something for a schemaless database. You still have a schema, it's just defined in your application code instead of the database layer. That needs thought, and therefore time.

Working with a schemaless 'nosql' database is only faster if you're skipping the part where you think about how you store and access your data. That makes your system less reliable.

Re: Yagni Exceptions (2021)

#47

Post by pjerem »

hardware2win wrote: post #44
onion2k wrote: post #26

Earlier quoted context omitted.

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!"

Even if it sounds, then what? Are you trying to say that NoSQL based systems are less reliable?

Nobody says they are not reliable. We just say that by not using RDBMS, your application is now responsible of your data cohesiveness.

Good luck when you discover that your production database is full of incoherent data because a bug in your application generated unusable data objects (missing fields, wrong structure …) that your NoSQL was happy to store without a problem.

In a relational database, you are 100% guaranteed that your data fits the schema. It’s not just tables and columns names. It’s uniqueness checks, it’s constraints, it’s what to do with your data when a related data is modified or deleted.

Re: Yagni Exceptions (2021)

#48

Post by hardware2win »

onion2k wrote: post #46
hardware2win wrote: post #44

Earlier quoted context omitted.

Even if it sounds, then what? Are you trying to say that NoSQL based systems are less reliable?

Nope. I'm saying that if your argument is "I'm choosing this tech because I'm slow at this other tech" then it's very likely you're making a poor choice. There's nothing inherently slow about designing a relational database. The work required takes time, but the same is true if you're designing something for a schemaless database. You still have a schema, it's just defined in your application code instead of the data…

>I'm saying that if your argument is "I'm choosing this tech because I'm slow at this other tech" then it's very likely you're making a poor choice.

We do it all the time as the industry.

We do web dev in langs like c# java instead of c cpp

Even despite the fact that cpp is capable of returning html text just fine.

>Working with a schemaless 'nosql' database is only faster if you're skipping the part where you think about how you store and access your data. That makes your system less reliable.

How so?

At worst performance may be not optimal

The question whether youll get to this point is hard to answer

How about the using nosql by default to enable rapid development and sql when theres a need for it?

Re: Yagni Exceptions (2021)

#49

Post by boxed »

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…

Djangos migration system is so good that migrations are basically a non-issue. Having worked with it a while it's really weird that more frameworks are still so radically behind.

Re: Yagni Exceptions (2021)

#50

Post by hardware2win »

pjerem wrote: post #47
hardware2win wrote: post #44

Earlier quoted context omitted.

Even if it sounds, then what? Are you trying to say that NoSQL based systems are less reliable?

Nobody says they are not reliable. We just say that by not using RDBMS, your application is now responsible of your data cohesiveness. Good luck when you discover that your production database is full of incoherent data because a bug in your application generated unusable data objects (missing fields, wrong structure …) that your NoSQL was happy to store without a problem. In a relational database, you are 100% guara…

Database integrity checks are only small part of integrity checks

You still must have those in code to operate on valid business object

I'd say that world has partly moved from programming in database and does it in code which can be easily covered with tests

Post reply on HN