Yagni Exceptions (2021)

Rarely do I read something so specific about software development that I agree with 100%.<p>One thing I would add: soft deletes in relational databases. There&#x27;s a really good chance that eventually you&#x27;ll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes.<p>For some types of businesses, I wonder if &quot;right to be forgotten&quot; should be designed in from the beginning as well. This can be a problem with hard deletes and with soft deletes. With soft deletes, well, it&#x27;s hard to figure out how to actually delete things if you&#x27;ve been growing a data model with soft deletes for a couple of years. With hard deletes, well, after you apply some hacks to prevent cascading deletes from killing your performance, now you&#x27;re in the same place. Maybe worse if your foreign keys are no longer an exhaustive guide to relationships. &quot;Right to be forgotten&quot; will be a nightmare if it hasn&#x27;t been designed in from the start. Obviously not every kind of business will have to worry about this, but I think the ones that do should consider putting some effort into making sure their design supports it.

This is very nearly off topic, but &quot;Ain&#x27;t&quot; is the correct conjugation to pair with &quot;Gonna&quot;. This form comes from Britain and is preserved in some dialects of American English, but &quot;Aren&#x27;t Gonna&quot; is a partial hypercorrection; if we want acrolect, we must go all the way to &quot;Aren&#x27;t Going To&quot;.<p>&quot;You gonna be at the thing this weekend?&quot;<p>&quot;Nah man I aren&#x27;t gonna&quot; &lt;-- this is <i>wrong</i><p>For the Commonweath, to whom this is no longer part of the language, &quot;You Aren&#x27;t Going to Need It&quot; is fine, no need to include the T.<p>Edit: I was drawing further attention to the actual grammatical distinction between &quot;ain&#x27;t&quot; and &quot;aren&#x27;t&quot; by showing that &quot;ain&#x27;t&quot; conjugates the first person and &quot;aren&#x27;t&quot; doesn&#x27;t.<p>It might help to know that &quot;going to&quot; is usually pronounced &quot;gonna&quot; unless it ends a clause, while &quot;gonna&quot; is more normally realized in speech as &quot;goan&quot;.<p>Even more: if you want to reify a partial hypercorrection, go ahead, I&#x27;m a descriptive linguist, say the &#x27;t&#x27; in often while you&#x27;re at it.<p>One of my grandfathers would have said something sounding like &quot;yain go need it&quot;, the other &quot;you aren&#x27;t goin a need it&quot;.<p>The latter I&#x27;m sure never said the word &quot;ain&#x27;t&quot; in his life. Nor would he have ever spelled &quot;going to&quot; as &quot;gonna&quot;, no matter what it sounds like when spoken.

* Having all user-facing strings in a common place.<p>It doesn&#x27;t take much effort, but makes it <i>so</i> much easier in the future when you suddenly either need internationalization&#x2F;translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it&#x27;s requested that these be managed by a cms of some sort instead of hardcoded all over the place.

&gt; I&#x27;m essentially a believer in You Aren&#x27;t Gonna Need It — the principle that you should add features to your software — including generality and abstraction<p>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 it &quot;doesn&#x27;t matter&quot;. But it does. Think twice before claiming that something is a principle. The words you use highly influence your thought process[0].<p>[0]: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Linguistic_relativity" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Linguistic_relativity</a>

Regarding the point about having a relational database:<p>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:<p>&gt; 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., &quot;give me all the users with the skills &quot;Java&quot; and &quot;OOP&quot; but not &quot;.net&quot;)<p>So, the non-relation model fits perfectly (so, we ended up using MongoDB and the `skill` attribute of &quot;User&quot; is just an array). I know it&#x27;s possible to use, let&#x27;s say, MySQL and build a couple of tables to achieve the same, but it just &quot;didn&#x27;t feel right&quot; (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)

YAGNI is about avoiding premature optimisation.<p>A lot of these make sense. But they always do. And the road to shipping hell is paved in good architectural practices.<p>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&#x27;d launch too late.<p>A lot of these YAGNI things are not &quot;you&#x27;re never going to need it&quot;, but just &quot;can we ship the first version without it?&quot;.

Should maybe add security and privacy to that list, in this day and age. Not that it all needs to be implemented right away (depending on jurisdiction you&#x27;re operating under) but having a plan for how to solve security and privacy considerations and working with that in mind from the start can make it a much less painful experience in the long run.

YAGNI as a whole, I&#x27;ve found, is an oversimplified hammer used to justify bad behavior and cutting corners. The engineers that quickly and happily throw around &quot;YAGNI&quot; have never had to deal with a Sev1 outage whereby you&#x27;re hemorrhaging money - often because you don&#x27;t exactly know where your system is failing because you don&#x27;t exactly have good logging&#x2F;tracing&#x2F;observability in place.<p>EDIT: this is not to say it doesn&#x27;t have utility. As a guiding thought it most certainly does. But it&#x27;s also easily abused.

I experienced a case of zero one many that would have been better if YAGNI was applied.<p>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.<p>And the system never needed multiuser chat.

&gt; 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.<p>In my experience, the timestamps should almost always be entered <i>in addition</i> to the flag.<p><pre><code> select * from data_journal where status = &#x27;Loading&#x27; </code></pre> is much easier to write and understand than<p><pre><code> select * from data_journal where started_loading_at is not null and finished_loading_at is null</code></pre>

&gt; Versioning APIs<p>I hear this recommended quite frequently, but I don&#x27;t see it practiced much, nor do I really understand what is being recommended. No matter how you wrote your first API you can always introduce a &#x2F;v2&#x2F; later, and no matter how good you get at versioning it&#x27;s still much worse than maintaining a well-designed backwards-compatible API. If anyone has recommended reading on this I&#x27;d love to check it out.

YAGNI is not an excuse to take lots of shortcuts against known good implementation patterns. Second guessing years of people doing things right by naively assuming you won&#x27;t need something is more likely to be a mistake than it is not. Do it properly the first time. Actively creating technical debt against your better judgment is silly.

I&#x27;m glad to see exceptions being discussed. I had a coworker who applied an almost religious adherence to YAGNI. We were building the next iteration of our build system and were applying the lessons of problems we had in the previous iteration and a coworker maneuvered management to take over the project and threw everything out because YAGNI. He wanted to start from scratch and get direct proof of problems for everything we designed into the system, throwing out all of the years of experience in supporting our build system and the limitations it had.

Cool list!<p>For Django developers I&#x27;ve compiled a list of Django guidelines that also contains a lot of yagni exceptions especially for Django: <a href="https:&#x2F;&#x2F;www.spapas.net&#x2F;2022&#x2F;09&#x2F;28&#x2F;django-guidelines&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.spapas.net&#x2F;2022&#x2F;09&#x2F;28&#x2F;django-guidelines&#x2F;</a>

I will play devil advocate<p>Relational databases add too much time overhead due to building schema or configuring orm for schema<p>Migrations management<p>Building an db model to domain model mapper and maintaining it<p>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<p>Nosql gives you modeling freedom which is handy for architects

I have to disagree with the first point in the article. The “zero, one, many” rule, or the related “rule of three” isn’t about how many items you have in your list, it’s about code reuse. The conclusion is correct though, that you should default to one:many relationships unless you know they are strictly one:one

And I thought it was going to be about how you shouldn&#x27;t use exceptions unless you really need them...

Kudos to the comments on databases. It is very hard to justify ripping out Mongo after the fact even if relational is better. Part of the problem is opportunity cost (“We need the money for innovation and new features”) and part is having to fess up to the wrong call to begin with.

&quot;By this I mean, if you need a database at all, you should jump to having a relational one straight away, and default to a relational schema, even if your earliest set of requirements could be served by a “document database” or some basic flat-file system. Most data is relational by nature, and a non-relational database is a very bad default for almost all applications.&quot;<p>That is terrible advice.<p>Relational databases are heavy weight solutions, expensive and slow.<p>Make a data interface from the start, yes. But start with backing with a flat file and exhaustive search. Simple, cheap, and more efficient than relational databases, indexing, sorting, and&#x2F;or binary searching until you have a lot of (for some definition of &quot;a lot of&quot;) data.

I agree will all of this, but it&#x27;s very much because my tooling make it easy to do so.<p>In some other stack, setting up good logging can be annoying and I understand you wanna take the shortcut.

Bad title. I read it as &quot;you ain&#x27;t gonna need exceptions&quot; but the author intended &quot;exceptions for the YAGNI-thumbrule&quot;.

Yagni is for justifying throwing crap at a wall until it sticks, not purposefully creating usable or maintainable software.

“Good logging” is mentioned here. Can somebody recommend a good write-up of what good logging consists of?

Pretty bad advice.<p>The good thing about YAGNI is that you can treat it as dogma and you&#x27;ll be fine. Sometimes you&#x27;ll be wrong, but it&#x27;s always going to be easy to recover from mistakes. Doesn&#x27;t matter how much experience you have, YAGNI is always a net positive.<p>Author&#x27;s recommendations on the other hand require a lot of caution. Take logging for example. It&#x27;s quite a slippery slope: how much logging is enough?<p>Just a few INFO statements here and there? Or multiple levels? Centralized logging? Structured logging? Alerts? What about retention? GDPR?<p>Good logging requires <i>thinking</i>.<p>You can always add more logging when necessary. But you cannot unadd the logging noise you accidentally introduced (well technically you can, but noone does it).<p>Zero-one-many: if 1% of your users needs two addresses, then 0.01% will need more than two. You can just say no to those. You avoided one level of abstraction by slightly upsetting 0.01% of your users. In most cases that&#x27;s a good thing: unlike MAU, complexity piles up and grows non-linearly.<p>Versioning: in most cases if you don&#x27;t control both ends of the API, versioning is a requirement, YAGNI doesn&#x27;t apply here. And when you do, versioning is a huge process change that rarely pays off.