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

171–180 of 214 posts

Re: Yagni Exceptions (2021)

#171

Post by BlargMcLarg »

Tyr42 wrote: post #155
dkarl wrote: post #152

Earlier quoted context omitted.

Not recover, but explain to the users that the data was deleted, and when it was deleted. If you have to provide support to customers, you will get a steady trickle of confused and angry customers wondering why their data disappeared after they (or their coworker, etc.) deleted it. Soft deletes let you answer those inquiries confidently with very little effort. With hard deletes, complaints like that can eat up suppo…

Perhaps Tombstones would be a better choice, where ether data is deleted, but a record of when and why is included instead?

Difference being here a tombstone doesn't contain enough information to recreate the record should it be necessary. Guess it's a tradeoff whether you want a graveyard you can use digital necromancy on, or simply an indicator why the data got yeeted.

Re: Yagni Exceptions (2021)

#172

Post by dkarl »

dkarl wrote: 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…

Too late to edit my original comment, but I'm surprised not to see more discussion about "right to be forgotten." It's legally mandated for some types of data in some jurisdictions, and it's hard to implement in a schema that has evolved without it. It doesn't affect the company I work at now, so I haven't had to think much about it, and I was hoping to hear from people who have.

Re: Yagni Exceptions (2021)

#173

Post by fknorangesite »

nine_k wrote: post #93
samatman wrote: post #78

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…

Shouldn't the "ain't" form require double negation, as in "you ain't gonna need no exceptions"? Then YAGNI would need to be transformed to something like YAGNNOI, "you ain't gonna need none of it". (An offtopic technicality comment being at the top on HN always amuses me.)

> Shouldn't the "ain't" form require double negation, as in "you ain't gonna need no exceptions"?

Only in some dialects.

Re: Yagni Exceptions (2021)

#174

Post by hinkley »

bazoom42 wrote: post #58
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.

Sure, but what if you never need to internationalize? Introducing a level of indirection have a cost. This is exactly why YAGNI applies. Refactor the code to support a requirement when the need arises .

Have you done that refactor? There is no timeline you can do once people are just injecting static text everywhere in the app.

That project is 'done' when the interval between bug reports increases past some number where people decide it's done. But if you tell your boss "next month" then you're going to be proven wrong.

Re: Yagni Exceptions (2021)

#175

Post by Izkata »

mikro2nd wrote: post #42
valenterry wrote: post #4

Bad title. I read it as "you ain't gonna need exceptions" but the author intended "exceptions for the YAGNI-thumbrule".

And I read it a third way: Exceptions you ain't gonna need. Any more offers?

I had "YAGNI as exceptions" - you start building out the extra functionality, but drop a NotImplementedException at each entrypoint for the extra functionality in the code.

Re: Yagni Exceptions (2021)

#176

Post by hinkley »

jaza wrote: post #108
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.

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…

There's hard coding strings, and then there's hard-coding sentence fragments.

If you hard code strings, you can't translate at all. If you hard-code sentence structure ("There are " + n + " copies of this book in stock") then you're going to sound like Yoda in a number of languages.

Adjectives are a particularly bad sticking point. Is it a large red book (English), a large book that is red (French), or a book that is large and red? But Verb-Object-Noun order also vary just within first world nations, so even the lame classist/racist/nationalistic excuse of "We don't need their money anyway" doesn't really fly. One of your competitors will be very happy to take Japan's money.

Re: Yagni Exceptions (2021)

#178

Post by hinkley »

taink wrote: post #53
robertlagrant wrote: post #35

Earlier quoted context omitted.

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.

Yes, I can think of Android Studio which pushes you into using Android's string resources[0], which have out-of-the-box support for i18n and are essentially big XML files. [0]: https://developer.android.com/guide/topics/resources/string-...

I haven't worked in Android, but a quick perusal at least passes my giggle test, which frankly too many languages do not.

This is essentially a refinement of the i18n support that has been in Java for ages. I probably would not have stuck with Java as long as I did if their localization support wasn't as good as it was (not to say it's perfect, because it's a bit clunky). Google has made a few of the examples into a more concrete requirement, which is nice.

Re: Yagni Exceptions (2021)

#179

Post by hinkley »

marcus_holmes wrote: post #92

YAGNI is about avoiding premature optimisation. A lot of these make sense. But they always do. And the road to shipping hell is paved in good architectural practices. To ship a first version of a product, we always need to cut corners. Deep, horrible, painful, cuts. Because if we spent the time to make the perfect product, we'd launch too late. A lot of these YAGNI things are not "you're never going to need it", but…

The hard lesson I learned during the dotcom era and immediately after is that this cult like worship of version 1 ends up sinking many companies but since it's new nobody wants to hear, it doesn't get reported well.

Any asshole can ship version 1. Shipping version 2 takes some talent.

In particular, to your scenario, there's a reason why companies operate in 'stealth' mode. The moment they are on the public radar, now all of the time frames are based on customer interest and customer complaints. We have to keep some tempo of releases to build customer confidence. You can't launch the MVP and then immediately stop all work to address the tech debt you acquired. So we're not talking about 'after MVP' versus 'before MVP', we are talking 'this year' versus 'next year or the year after'. That's a long time to creak along with very bad initial architecture decisions.

The value of a coach in sports or other activities is that this is a person who is not bogged down by the minutiae of the performance. They can see when you're stuck and tell you to stop. Very, very few developers have the ability to self-coach. It's one of the purposes of the morning standup: the hope that you hear yourself saying you've been wrapped around the axle on something and need a change of perspective. But the "stuckness" I'm talking about here has to do with Sharpening Your Axe. You're in a bad way because your 'tools' are not 'sharp', but you've already panicked about deadlines so you keep muscling through instead of realizing that the fastest way to complete tasks is to make the tasks easier and then do the task. That's the sort of tech debt that gets devs angry and resentful of people who tell them 'no'.

Re: Yagni Exceptions (2021)

#180

Post by hinkley »

galangalalgol wrote: post #114
marcus_holmes wrote: post #92

YAGNI is about avoiding premature optimisation. A lot of these make sense. But they always do. And the road to shipping hell is paved in good architectural practices. To ship a first version of a product, we always need to cut corners. Deep, horrible, painful, cuts. Because if we spent the time to make the perfect product, we'd launch too late. A lot of these YAGNI things are not "you're never going to need it", but…

I agree that we have to be very vigilant against the what ifs, but with the exception of logging, which is the one I most disagree with (unless it is helping you debug a failed test), these all seem like cases where the future thinking thing takes precisely as much time as the ship-it-now thing. The versioning thing could get really out of hand too probably now that I think about it. But timestamps, many vs two, and…

I irritate myself constantly by realizing that this bug fix I'm working on would have been easier if I'd written some better tests first. Or noticed the order of a couple of log messages sooner.
Post reply on HN