Rarely do I read something so specific about software development that I agree with 100%. One thing I would add: soft deletes in relational databases. There's a really good chance that eventually you'll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes. For some types of businesses, I wonder if "right to be forgotten" should be designed in from the beginning a…
Soft deletes can be thought of as a combination of versioning and timestamps. By using the Sixth Normal Form (6NF) with timestamps in the key, you get those for free, but this kind of schema may be a bit too complex for many simpler applications.
Yagni Exceptions (2021)
141–150 of 214 posts
Re: Yagni Exceptions (2021)
#142This 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…
Re: Yagni Exceptions (2021)
#143Earlier quoted context omitted.
Exceptions are the worst, except for any other way of handling errors.
I agree, but your sentence is empty: errors do not exist, they are just conditions that you dislike . Do not let your emotions affect the syntax for control flow!
Re: Yagni Exceptions (2021)
#144This 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…
I used to argue for “amn’t” as in “I amn’t going to need it” but none of my elementary school teachers were persuadable.
Re: Yagni Exceptions (2021)
#145Earlier quoted context omitted.
If adding these things really slows your ability to ship the first version of your product, you need to fire your team and start with a new one. These PAGNIs are: 1. log.info() calls 2. apt-get install postgresql 3. Using timestamp and datetime.now() instead of boolean fields 4. Adding a /v1/ into your API endpoints I'm being serious. If your team says "this will add a week onto the release date" then your team is ei…
Sure, but it escalates quickly. Logging goes from `log.Println("the thing happened")` to structured logging via an API very easily. Adding Postgres is a no-brainer. Totally agree. But should you architect the database properly? It's going to be tricky to normalise data later, maybe we should start with properly normalised tables now, instead of jamming everything into a jsonb field? Versioning, sure, but does every A…
I'd think it's implied that you just normalise the tables. It's really not hard to build and use a normalised database. I was doing this in my first months as a junior developer, so I'd expect an engineer with any seniority to be able to do it.
If you're asking: "should we model the domain perfectly?" then my answer is a simple "model the domain as you understand it _today_." YAGNI is not "write shitty code" but "don't add things you don't need right now."
Again, if adding /v1/ into your first URL string or configuring your logging takes "a couple days" each, then I'm going to have serious concerns.
Re: Yagni Exceptions (2021)
#146Earlier quoted context omitted.
Soft deletes can be thought of as a combination of versioning and timestamps. By using the Sixth Normal Form (6NF) with timestamps in the key, you get those for free, but this kind of schema may be a bit too complex for many simpler applications.
Can you point to an example please?
I guess with timeseries you'd have something along the lines of:
user | time_range | status
======+==============+=========
1 | [2018, 2021) | ACTIVE
2 | [2019, ) | ACTIVE
1 | [2021, ) | BLOCKED
Where the PK is (user, time_range). (The time_range field being shortened to just year here for simplicity's sake.)In PostgreSQL you can use the tstzrange[2] type. You could also only store one of the timestamps, but that would come at the cost of more complex queries.
[1]: https://en.wikipedia.org/wiki/Sixth_normal_form#Examples
[2]: https://www.postgresql.org/docs/current/rangetypes.html
Re: Yagni Exceptions (2021)
#147Earlier quoted context omitted.
If adding these things really slows your ability to ship the first version of your product, you need to fire your team and start with a new one. These PAGNIs are: 1. log.info() calls 2. apt-get install postgresql 3. Using timestamp and datetime.now() instead of boolean fields 4. Adding a /v1/ into your API endpoints I'm being serious. If your team says "this will add a week onto the release date" then your team is ei…
If it is just API endpoints, but I can see some junior dev spending time putting version numbers on literally every data structure, taking the exception as a rule. And when logs go from "huh, if this happens I want to know about" type thoughts as you are coding to "lets make a full pass and see where I could have added some logs to this PR" then effort is being spent too far in advance. I definitely agree timestamps,…
That's a strawman argument.
> And when logs go from "huh, if this happens I want to know about" type thoughts as you are coding to "lets make a full pass and see where I could have added some logs to this PR" then effort is being spent too far in advance.
That's a strawman argument.
> have to use something like an ECS for performance reasons. This is pretty common for embedded or game domains.
If your domain requires something else, you probably already know it.
Re: Yagni Exceptions (2021)
#148This 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…
Re: Yagni Exceptions (2021)
#149* 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 once worked on a large app that had always tried to support translation, but that had never actually been used by clients (after more than a decade running in production) in a language other than English. Well, what do you know, after all those years, finally a big client signed on, and this client needed the whole UI not in English. Trouble was, in practice there were gaps in the translation support all over the p…
I wish I had a box of nickels for every feature that cost $100k+ to implement that ended up being a dead end (i.e., sales benefit never materialized) or, even more commonly, the benefit materialized and was less than $100k and resulted in a feature that required continued maintenance and ongoing support cost forever.
Re: Yagni Exceptions (2021)
#150Rarely do I read something so specific about software development that I agree with 100%. One thing I would add: soft deletes in relational databases. There's a really good chance that eventually you'll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes. For some types of businesses, I wonder if "right to be forgotten" should be designed in from the beginning a…
Can't agree with you there. I've never seen a situation in which it was necessary to recover "optimistically" soft-deleted data. I have seen multiple situations in which soft-deleted data was accidentally included in live queries.
Yes - backups can help - but without live backups (WAL shipping or equivalent) you still risk some form of data loss. And if you have those, you just have soft deletes on a system level rather than an in-DB level + a vastly more complex system of partial restores.