Live data from Hacker News

Yagni Exceptions (2021)

lukeplant.me.uk

141–150 of 214 posts

Re: Yagni Exceptions (2021)

#141
post #123

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.

Can you point to an example please?

Re: Yagni Exceptions (2021)

#142

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…

You goan dun bikesheddin'

Re: Yagni Exceptions (2021)

#143
post #101

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

Great, I will tell that to my customers!

Re: Yagni Exceptions (2021)

#144
post #105

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…

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.

Fully in-use in Scotland and Ireland

Re: Yagni Exceptions (2021)

#145

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

The detail you're going into are the YAGNI part. Yes, you'll get those eventually, but you deal with _those_ problems later. Log to a file right now and switch to DataDog, Papertrail, etc. later on. Add /v1/ now, worry about integrating CI/CD into that later, when breaking changes means you actually need to worry about using versioning.

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)

#146

Earlier 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?

Wikipedia has a couple of non-timeseries examples[1].

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)

#147

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

> I can see some junior dev spending time putting version numbers on literally every data structure

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)

#148

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…

This is flat-out wrong pseudogrammatical criticism. I say "aren't gonna" all the time. "Gonna" is a very common spoken contraction, used much more broadly than "ain't" in AmE.

Re: Yagni Exceptions (2021)

#149
post #108

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

Not too ironic I think, more common than not.

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)

#150
post #123

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…

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.

From a customer support PoV, soft deletes have the wonderful property that you can assuage the upset / irate individual on the other end of the phone that their data can indeed be recovered from whatever mishap they just engineered and do so with a simple query.

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.

Post reply on HN