17 ms·

Yagni Exceptions (2021)

290 points by bubblehack3r 4y ago

mhaymo 4y ago
> Versioning APIs I hear this recommended quite frequently, but I don'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 /v2/ later, and no matter how good you get at versioning it's still much worse than maintaining a well-designed backwards-compatible API. If anyone has recommended reading on this I'd love to check it out.
satyanash 4y ago
> I'm essentially a believer in You Aren't Gonna Need It — the principle that you should add features to your software — including generality and abstraction 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 "doesn't matter". But it does. Think twice before claiming that something is a principle. The words you use highly influence your thought process[0]. [0]: https://en.wikipedia.org/wiki/Linguistic_relativity https://en.wikipedia.org/wiki/Linguistic_relativity
- FeepingCreature 4y ago
  Indeed. A rule of thumb is something you're supposed to use, at most, in the absence of any better information. I've written abstractions that didn't end up needed, sure. I've also written abstractions that I've been extremely glad for in hindsight.
- bazoom42 4y ago
  So what would be an example of a software design principle?
  - EdwardDiego 4y ago
    Never write a function called destroyBaghdad(). Instead name it destroyCity and pass the target as a parameter.
    - dagw 4y ago
      If Baghdad is city your users destroy most often, I would allow a destroyBaghdad() function that calls destroyCity() with all parameters set correctly.
      - samatman 4y ago
        This is why the US destroyed Baghdad. The contract is called CongressAuthorizesInvadingCountry(country :Country): Invasion Congress made a thunk with Iraq in it, so despite the lack of any real connection to Recent Events, the White House called it in 2003.
    - gdy 4y ago
      Ugh. Try writing destroyKiev instead and see what happens.
      - EdwardDiego 4y ago
        Last time I tried, I got a 404 Competent Military Not Found error. :/
        gdy 4y ago
        My point was that neither routune should ever be written and the Middle East would've been much better off if the world had started an all-out economic war against the US in 2003. In case you are wondering, I'm Russian, have friends in the Ukraine and destroyed Kiev is the last thing I want. Jokes about destroying Baghdad are just callous. Especially coming from Americans.
        EdwardDiego 4y ago
        Good thing I'm not American then. (And the joke I'm referencing is making fun of software ethics, so you're in violent agreement.)
- EdwardDiego 4y ago
  > 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 sure what difference you perceive - principles are often derived from experience, as well as theory, and they often have exceptions too. Many people have a principle of not committing violence, for example. _Except_ when (multiple clauses follow).
  - gpderetta 4y ago
    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.
    - EdwardDiego 4y ago
      > 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.)
      - galangalalgol 4y ago
        That is because DRY sets a puzzle for us, how to cleanly reuse some code. YAGNI on the other hand, denies us a puzzle. We like puzzles.
        EdwardDiego 4y ago
        I like your thinking on this
- Vinnl 4y ago
  > The words you use highly influence your thought process Given that the article is literally about exceptions to YAGNI, and explicitly calls out that there are probably more, their use of the term "principle" doesn't appear to have caused them any harm.
- samhuk 4y ago
  Your semantical argument of "principle" vs "contextual rule of thumb" is incorrect. They mean the same thing in almost every context, according to any dictionary/thesaurus you find out there. In fact, the ultimate defining characteristic of a "principle" is that it has exceptions and should not be used as the "ultimate word of God". Even in Physics, where most would think a "principle" means something "without exception", they are only ever currently without exception according to current evidence. There has been countless times where there has been a scientific principle only to be disproven later on. Lastly, you link Sapir–Whorf, which, quite ironically, is considered a "principle" yet has had much criticism over time, which contradicts your own argument. However, I will agree with you that one should always be careful of the language they use since it can affect how others view your thoughts, feelings, and intentions.
- Supermancho 4y ago
  > This can apply to protocols, APIs, file formats etc. It is good to think about how, for example, a client/server system will detect and respond to different versions ahead of time (i.e. even when there is only one version), A blogpost/article about YAGNI manages to suggest a rather nuanced feature should always be included, that isn't needed, right up front.
- westernpopular 4y ago
  You say > The words you use highly influence your thought process[0]. Yet in the very article you link it says (emphasis mine) > The strong version, or linguistic determinism, says that language determines thought and that linguistic categories limit and determine cognitive categories. This version is generally agreed to be false by modern linguists.[3] > The weak version says that linguistic categories and usage only influence thought and decisions.[4] Research on weaker forms has produced positive empirical evidence for a relationship.[3] Your use of 'highly' would suggest a strong relativity, but that's discredited. Signed, a disgruntled linguist who's tired of people banging on about Sapir-Whorf.
valenterry 4y ago
Bad title. I read it as "you ain't gonna need exceptions" but the author intended "exceptions for the YAGNI-thumbrule".
- dmichulke 4y ago
  It's only bad if you read "YAGN Exceptions"
  - enriquto 4y ago
    But this would be very good advice! Exceptions (a.k.a. modern-flavored COMEFROM statements[0]) are extremely confusing and have no place in a clean codebase. [0] https://en.wikipedia.org/wiki/COMEFROM https://en.wikipedia.org/wiki/COMEFROM
    - wruza 4y ago
      Exceptions do not specify from where exactly they should “come from” and are two-way protocol akin to setjmp/longjmp. Situations where exit through few levels of stack is required do happen regardless of code cleanness, and the only alternative is to pair every call with a flow control statement, turn primary return value into a status, and add two out-arguments for error and result. Some people love this, some not really.
    - goto11 4y ago
      Exceptions are the worst, except for any other way of handling errors.
      - enriquto 4y ago
        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!
        goto11 4y ago
soft_dev_person 4y ago
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'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.
- gherkinnn 4y ago
  You are correct. How would you distill this in to a handful of elements akin this submission?
  - soft_dev_person 4y ago
    I probably wouldn't, since it is very use case specific what concerns are relevant. So more a suggestion to get an overview of the security requirements and privacy requirements one needs to deal with at some point and sketch some possible ways to make those requirements easy to solve when the time comes. Examples of things to consider: zero trust, multi tenancy, permission structures, user data classification (for GDPR removal/extraction requests). As a European, GDPR has far reaching consequences that may even dictate what other services you rely on. I.e. can you use that SaaS service for your product when it's located outside of the EU/EEC?
jillesvangurp 4y ago
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'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.
- bazoom42 4y ago
  > YAGNI is not an excuse to take lots of shortcuts against known good implementation patterns. I’d say it is, because “best practices” and “patterns” are usually context dependent and will have a negative cost when applied when not needed.
- gpderetta 4y ago
  Abstraction is critical, but it is also very hard. Unneeded and wrong abstraction creates more technical debt than no abstraction. A simpler design is easier to extend, and worst case rewrite, than a more complex, abstract design. If you know by experience, personal or otherwise, that a design or abstraction is sound, and you know you are very likely to need it in the future, go for it. Otherwise, YAGNI.
danwee 4y ago
Regarding the point about having a relational database: 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: > 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., "give me all the users with the skills "Java" and "OOP" but not ".net") So, the non-relation model fits perfectly (so, we ended up using MongoDB and the `skill` attribute of "User" is just an array). I know it's possible to use, let's say, MySQL and build a couple of tables to achieve the same, but it just "didn't feel right" (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)
- awestroke 4y ago
  Am I missing something, or could you have achieved the same thing with a relational database using joins? Or even an array-typed column?
  - deleted 4y ago
    [deleted]
  - danwee 4y ago
    That's what I wrote yes. I could also have achieved the same using the file system and plain files, or using a graph database. My point is/was: the document model seemed to us the model that fit the best for our problem: the `skills` attribute is an unbounded list (well, in practice the list was bounded to have at most 50 items) that can be filtered by. So in MongoDB, that's plain simple to implement. In MySQL, though, as you said, you have to come up with two tables (one for `user`, one for `skills`, make sure FK are in place, and then use joins for filtering... doesn't seem to me that this model fits better)
    - awestroke 4y ago
      I interpreted your comment as you claiming a view would have been needed. The list of things required in a relational database does not seem long to me. I could probably come up with an even longer list for what's required when using Mongo. Also, my point about an array typed column still stands
syastrov 4y ago
I experienced a case of zero one many that would have been better if YAGNI was applied. 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. And the system never needed multiuser chat.
- forgotmypw17 4y ago
  Isn't this, technically, a case of "one", since it's one user messaging one user?
  - syastrov 4y ago
    Yes, you are right. I was just mentioning the name of the principle as used in the article.
matsemann 4y ago
* 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.
- robertlagrant 4y ago
  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.
  - taink 4y ago
    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-resource https://developer.android.com/guide/topics/resources/string-...
    - hinkley 4y ago
      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.
- iLoveOncall 4y ago
  I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plurals and others. I just want to write my damn text. I'd rather spend days doing the mind-numbing work when needed rather than slow down my development process and remove all enjoyment from it ad vitam aeternam because of i18n-ing on the fly.
orthoxerox 4y ago
> 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. In my experience, the timestamps should almost always be entered in addition to the flag. select * from data_journal where status = 'Loading' is much easier to write and understand than select * from data_journal where started_loading_at is not null and finished_loading_at is null
- number6 4y ago
  If you have to answer: "does it usually take so long or is something broken?" The Timestamps would be handy. Oh and you can estimate an average for the execution time; investigate performance degradation or improvements
  - orthoxerox 4y ago
    Yes, that's why I've written it's better to have both.
  - deleted 4y ago
    [deleted]
- Vinnl 4y ago
  Feels like maybe a view on top your table that adds the boolean based on the timestamp might be safer, in that by definition there's no risk of the two columns getting out of sync?
- motogpjimbo 4y ago
  This sounds like you're opening yourself up to situations where you have rows in data_journal that have status='Loading' but which have started_loading_at=NULL, in violation of your data model. Your premise is slightly flawed in that your second example isn't actually difficult to write or understand as you claim. However, it could be argued that if the logic for selecting "loading" rows is repeated in multiple places then a layer of abstraction over it would be useful. This could be achieved in SQL by e.g. CREATE VIEW loading_entries AS SELECT * FROM data_journal WHERE started_loading_at IS NOT NULL AND finished_loading_at IS NULL or, if you have several such statuses you need to define, CREATE VIEW data_journal_view AS SELECT data_journal.*, CASE WHEN started_loading_at IS NOT NULL AND finished_loading_at IS NULL THEN 'Loading' WHEN ... THEN ... ELSE 'Some other status' END AS status FROM data_journal
hardware2win 4y ago
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 architects
- CodesInChaos 4y ago
  You might want to take a look at EdgeDB. You still have to define a schema, but both its data model and query language have much smaller mismatch with popular programming languages and APIs, so you don't need a complex ORM. For example it has first class support for following links (instead of awkwardly joining on foreign keys), outputting nested data and polymorphism.
- onion2k 4y ago
  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!"
  - hardware2win 4y ago
    Even if it sounds, then what? Are you trying to say that NoSQL based systems are less reliable?
    - onion2k 4y ago
      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.
mattclarkdotnet 4y ago
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
- healsjnr1 4y ago
  I don't know that I completely follow on this comment, in particular how code reuse comes into it. I think the biggest thing is about deciding whether you have one or many. There are a lot of cases where having many doesn't just mean there is a list to show. In a lot of cases, having many means you now need to choose "the right one" to show/edit/action whatever. This brings up all sorts of complications beyond "just return a list instead of a single item". Even if you don't end up building it out, I think it always a good thought experiment during the design phase to think about how things would behave if there where multiple of key resources, rather than just one. Would it have implications elsewhere? Are there low cost alterations to the design that can be made now that make space / allow for this key resources to be a list later on? How hard would it these be to do later? I'm many cases the conclusion might be it isn't worth it and that's the right choice (yagni applied judiciously), but every now and again this might highlight a valuable early stage change that would have cost a lot to make later on.
  - code_runner 4y ago
    I took this as “if you need more than one, plan for storing ANYTHING greater 1 or greater” Meaning that if I need to store specifically 2 addresses per user, don’t force it at the data layer… just make it an easy to swap validation and no literal limits elsewhere
  - mattclarkdotnet 4y ago
    For display/view purposes, yes you need to decide what the likely option is. For model/type purposes, the decision to have a 1:1 relationship should be made only with great care, as the OP shows with the example of addresses.
samatman 4y ago
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" <-- this is wrong For the Commonweath, to whom this is no longer part of the language, "You Aren't Going to Need It" is fine, no need to include the T. Edit: I was drawing further attention to the actual grammatical distinction between "ain't" and "aren't" by showing that "ain't" conjugates the first person and "aren't" doesn't. It might help to know that "going to" is usually pronounced "gonna" unless it ends a clause, while "gonna" is more normally realized in speech as "goan". Even more: if you want to reify a partial hypercorrection, go ahead, I'm a descriptive linguist, say the 't' in often while you're at it. One of my grandfathers would have said something sounding like "yain go need it", the other "you aren't goin a need it". The latter I'm sure never said the word "ain't" in his life. Nor would he have ever spelled "going to" as "gonna", no matter what it sounds like when spoken.
- BerislavLopac 4y ago
  > This form comes from Britain All forms of English, ultimately, come from Britain.
- grey_earthling 4y ago
  “You aren't gonna need it” is ordinary colloquial British English. “I aren't…” is not.
  - RickHull 4y ago
    You're not gonna need it I'm not gonna need it You aren't gonna need it I amn't gonna need it You ain't gonna need it I ain't gonna need it
    - pindab0ter 4y ago
      You'ren't gonna need it.
marcus_holmes 4y ago
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 just "can we ship the first version without it?".
- scott_w 4y ago
  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 either very junior or bullshitting you.
  - galangalalgol 4y ago
    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, two vs many, and don't reinvent the database (or don't assume your db is flat) are effort free and always worth it. With the caveat that you maybe can't afford the overhead of a full rel db, and have to use something like an ECS for performance reasons. This is pretty common for embedded or game domains.
    - scott_w 4y ago
      > 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.
brodouevencode 4y ago
YAGNI as a whole, I've found, is an oversimplified hammer used to justify bad behavior and cutting corners. The engineers that quickly and happily throw around "YAGNI" have never had to deal with a Sev1 outage whereby you're hemorrhaging money - often because you don't exactly know where your system is failing because you don't exactly have good logging/tracing/observability in place. EDIT: this is not to say it doesn't have utility. As a guiding thought it most certainly does. But it's also easily abused.
spapas82 4y ago
Cool list! For Django developers I've compiled a list of Django guidelines that also contains a lot of yagni exceptions especially for Django: https://www.spapas.net/2022/09/28/django-guidelines/ https://www.spapas.net/2022/09/28/django-guidelines/
- BiteCode_dev 4y ago
  Clicked on the link expecting to see the usual beginners advices, but I'm plaisantly surprised that I would give most of the same recommendations to my team.
  - spapas82 4y ago
    Thank you for you kind words!
pindab0ter 4y ago
“Good logging” is mentioned here. Can somebody recommend a good write-up of what good logging consists of?
- sethammons 4y ago
  I've wanted to do that for a while. Look into structured logging. I want/need machines to analyze my logs, and that requires key value pairs. I put any dynamic text in its own field. "error for user 42, remote api timed out" -> level: error, userid: 42, message: api timeout, http_request: <curl call to reproduce>, timestamp: <curr_time>, time_duration_ms: 30000, ... (but as json). Now I can see what users are affected by which errors however often. Alerts are now trivial to implement. They key is being able to debug an issue after the fact. I like to include a copy-pastable curl call when I can so I can manually reproduce an issue easily as an example
  - pindab0ter 4y ago
    This is great. We use Sentry for our projects, which serves the same purpose. I was wondering if using info statements in certain places are seen as a good practice, for example.
  - 0cf8612b2e1e 4y ago
    The curl request log is a very interesting idea I have never seen before. Do you have a library recommendation or did you implement something yourself?
mathattack 4y ago
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.
dkarl 4y ago
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 as well. This can be a problem with hard deletes and with soft deletes. With soft deletes, well, it's hard to figure out how to actually delete things if you'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're in the same place. Maybe worse if your foreign keys are no longer an exhaustive guide to relationships. "Right to be forgotten" will be a nightmare if it hasn'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.
- ainar-g 4y ago
  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.
  - zasdffaa 4y ago
    Can you point to an example please?
    - ainar-g 4y ago
      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 https://en.wikipedia.org/wiki/Sixth_normal_form#Examples [2]: https://www.postgresql.org/docs/current/rangetypes.html https://www.postgresql.org/docs/current/rangetypes.html
epage 4y ago
I'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.
BiteCode_dev 4y ago
I agree will all of this, but it's very much because my tooling make it easy to do so. In some other stack, setting up good logging can be annoying and I understand you wanna take the shortcut.
ParetoOptimal 4y ago
Yagni is for justifying throwing crap at a wall until it sticks, not purposefully creating usable or maintainable software.
wizofaus 4y ago
And I thought it was going to be about how you shouldn't use exceptions unless you really need them...
worik 4y ago
"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." That is terrible advice. Relational databases are heavy weight solutions, expensive and slow. 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/or binary searching until you have a lot of (for some definition of "a lot of") data.
- tantaman 4y ago
  sqlite is lightweight, cheap, easy and faster than fopen :) https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/fasterthanfs.html
  - worik 4y ago
    Adding dependencies to solve simple problems is foolish. I have seen many projects get bogged down in complications around interfaces to third party software. Where the 3rd party software solved some simple problem that could easily be solved in a few dozen lines of code. Databases are one of the main offenders. But command line processing is probably the worst offender I see. Simple problems should use simple problems. Most data storage problems are simple. How much code is in sqlite? I do not know. But opening a flat file, gulping in the contents, linearly searching for the blob of data you want is simple, often fast enough, can be implemented in the time it takes to find, download, install,... some package from a third party. As I said: make an interface (probably three lines of code) and put the simplest thing possible behind it. (That simplest thing will not be sqlite). If requirements expand, put something more capable behind the interface. Another thing: Most data is not relational. I have seen systems that put apache log files into SQL databases. I imagine there might be sensible uses for that, but I cannot think of any. Golly, KISS is not some random acronym written by fools. It is a fundamental principal of software design "Go straight to relational database" is not a sensible principal of anything. It is bad advice.
hbrn 4y ago
Pretty bad advice. The good thing about YAGNI is that you can treat it as dogma and you'll be fine. Sometimes you'll be wrong, but it's always going to be easy to recover from mistakes. Doesn't matter how much experience you have, YAGNI is always a net positive. Author's recommendations on the other hand require a lot of caution. Take logging for example. It's quite a slippery slope: how much logging is enough? Just a few INFO statements here and there? Or multiple levels? Centralized logging? Structured logging? Alerts? What about retention? GDPR? Good logging requires thinking. 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). 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's a good thing: unlike MAU, complexity piles up and grows non-linearly. Versioning: in most cases if you don't control both ends of the API, versioning is a requirement, YAGNI doesn't apply here. And when you do, versioning is a huge process change that rarely pays off.

290 points by bubblehack3r 4y ago

> Versioning APIs I hear this recommended quite frequently, but I don'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 /v2/ later, and no matter how good you get at versioning it's still much worse than maintaining a well-designed backwards-compatible API. If anyone has recommended reading on this I'd love to check it out.

satyanash 4y ago

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

FeepingCreature 4y ago
Indeed. A rule of thumb is something you're supposed to use, at most, in the absence of any better information. I've written abstractions that didn't end up needed, sure. I've also written abstractions that I've been extremely glad for in hindsight.
bazoom42 4y ago
So what would be an example of a software design principle?
- EdwardDiego 4y ago
  Never write a function called destroyBaghdad(). Instead name it destroyCity and pass the target as a parameter.
  - dagw 4y ago
    If Baghdad is city your users destroy most often, I would allow a destroyBaghdad() function that calls destroyCity() with all parameters set correctly.
    - samatman 4y ago
      This is why the US destroyed Baghdad. The contract is called CongressAuthorizesInvadingCountry(country :Country): Invasion Congress made a thunk with Iraq in it, so despite the lack of any real connection to Recent Events, the White House called it in 2003.
  - gdy 4y ago
    Ugh. Try writing destroyKiev instead and see what happens.
    - EdwardDiego 4y ago
      Last time I tried, I got a 404 Competent Military Not Found error. :/
      - gdy 4y ago
        My point was that neither routune should ever be written and the Middle East would've been much better off if the world had started an all-out economic war against the US in 2003. In case you are wondering, I'm Russian, have friends in the Ukraine and destroyed Kiev is the last thing I want. Jokes about destroying Baghdad are just callous. Especially coming from Americans.
        EdwardDiego 4y ago
        Good thing I'm not American then. (And the joke I'm referencing is making fun of software ethics, so you're in violent agreement.)
EdwardDiego 4y ago
> 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 sure what difference you perceive - principles are often derived from experience, as well as theory, and they often have exceptions too. Many people have a principle of not committing violence, for example. _Except_ when (multiple clauses follow).
- gpderetta 4y ago
  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.
  - EdwardDiego 4y ago
    > 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.)
    - galangalalgol 4y ago
      That is because DRY sets a puzzle for us, how to cleanly reuse some code. YAGNI on the other hand, denies us a puzzle. We like puzzles.
      - EdwardDiego 4y ago
        I like your thinking on this
Vinnl 4y ago
> The words you use highly influence your thought process Given that the article is literally about exceptions to YAGNI, and explicitly calls out that there are probably more, their use of the term "principle" doesn't appear to have caused them any harm.
samhuk 4y ago
Your semantical argument of "principle" vs "contextual rule of thumb" is incorrect. They mean the same thing in almost every context, according to any dictionary/thesaurus you find out there. In fact, the ultimate defining characteristic of a "principle" is that it has exceptions and should not be used as the "ultimate word of God". Even in Physics, where most would think a "principle" means something "without exception", they are only ever currently without exception according to current evidence. There has been countless times where there has been a scientific principle only to be disproven later on. Lastly, you link Sapir–Whorf, which, quite ironically, is considered a "principle" yet has had much criticism over time, which contradicts your own argument. However, I will agree with you that one should always be careful of the language they use since it can affect how others view your thoughts, feelings, and intentions.
Supermancho 4y ago
> This can apply to protocols, APIs, file formats etc. It is good to think about how, for example, a client/server system will detect and respond to different versions ahead of time (i.e. even when there is only one version), A blogpost/article about YAGNI manages to suggest a rather nuanced feature should always be included, that isn't needed, right up front.
westernpopular 4y ago
You say > The words you use highly influence your thought process[0]. Yet in the very article you link it says (emphasis mine) > The strong version, or linguistic determinism, says that language determines thought and that linguistic categories limit and determine cognitive categories. This version is generally agreed to be false by modern linguists.[3] > The weak version says that linguistic categories and usage only influence thought and decisions.[4] Research on weaker forms has produced positive empirical evidence for a relationship.[3] Your use of 'highly' would suggest a strong relativity, but that's discredited. Signed, a disgruntled linguist who's tired of people banging on about Sapir-Whorf.

valenterry 4y ago

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

dmichulke 4y ago
It's only bad if you read "YAGN Exceptions"
- enriquto 4y ago
  But this would be very good advice! Exceptions (a.k.a. modern-flavored COMEFROM statements[0]) are extremely confusing and have no place in a clean codebase. [0] https://en.wikipedia.org/wiki/COMEFROM https://en.wikipedia.org/wiki/COMEFROM
  - wruza 4y ago
    Exceptions do not specify from where exactly they should “come from” and are two-way protocol akin to setjmp/longjmp. Situations where exit through few levels of stack is required do happen regardless of code cleanness, and the only alternative is to pair every call with a flow control statement, turn primary return value into a status, and add two out-arguments for error and result. Some people love this, some not really.
  - goto11 4y ago
    Exceptions are the worst, except for any other way of handling errors.
    - enriquto 4y ago
      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!
      - goto11 4y ago

soft_dev_person 4y ago

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

gherkinnn 4y ago
You are correct. How would you distill this in to a handful of elements akin this submission?
- soft_dev_person 4y ago
  I probably wouldn't, since it is very use case specific what concerns are relevant. So more a suggestion to get an overview of the security requirements and privacy requirements one needs to deal with at some point and sketch some possible ways to make those requirements easy to solve when the time comes. Examples of things to consider: zero trust, multi tenancy, permission structures, user data classification (for GDPR removal/extraction requests). As a European, GDPR has far reaching consequences that may even dictate what other services you rely on. I.e. can you use that SaaS service for your product when it's located outside of the EU/EEC?

jillesvangurp 4y ago

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

bazoom42 4y ago
> YAGNI is not an excuse to take lots of shortcuts against known good implementation patterns. I’d say it is, because “best practices” and “patterns” are usually context dependent and will have a negative cost when applied when not needed.
gpderetta 4y ago
Abstraction is critical, but it is also very hard. Unneeded and wrong abstraction creates more technical debt than no abstraction. A simpler design is easier to extend, and worst case rewrite, than a more complex, abstract design. If you know by experience, personal or otherwise, that a design or abstraction is sound, and you know you are very likely to need it in the future, go for it. Otherwise, YAGNI.

danwee 4y ago

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

awestroke 4y ago
Am I missing something, or could you have achieved the same thing with a relational database using joins? Or even an array-typed column?
- deleted 4y ago
  [deleted]
- danwee 4y ago
  That's what I wrote yes. I could also have achieved the same using the file system and plain files, or using a graph database. My point is/was: the document model seemed to us the model that fit the best for our problem: the `skills` attribute is an unbounded list (well, in practice the list was bounded to have at most 50 items) that can be filtered by. So in MongoDB, that's plain simple to implement. In MySQL, though, as you said, you have to come up with two tables (one for `user`, one for `skills`, make sure FK are in place, and then use joins for filtering... doesn't seem to me that this model fits better)
  - awestroke 4y ago
    I interpreted your comment as you claiming a view would have been needed. The list of things required in a relational database does not seem long to me. I could probably come up with an even longer list for what's required when using Mongo. Also, my point about an array typed column still stands

syastrov 4y ago

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

forgotmypw17 4y ago
Isn't this, technically, a case of "one", since it's one user messaging one user?
- syastrov 4y ago
  Yes, you are right. I was just mentioning the name of the principle as used in the article.

matsemann 4y ago

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

robertlagrant 4y ago
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.
- taink 4y ago
  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-resource https://developer.android.com/guide/topics/resources/string-...
  - hinkley 4y ago
    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.
iLoveOncall 4y ago
I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plurals and others. I just want to write my damn text. I'd rather spend days doing the mind-numbing work when needed rather than slow down my development process and remove all enjoyment from it ad vitam aeternam because of i18n-ing on the fly.

orthoxerox 4y ago

> 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. In my experience, the timestamps should almost always be entered in addition to the flag. select * from data_journal where status = 'Loading' is much easier to write and understand than select * from data_journal where started_loading_at is not null and finished_loading_at is null

number6 4y ago
If you have to answer: "does it usually take so long or is something broken?" The Timestamps would be handy. Oh and you can estimate an average for the execution time; investigate performance degradation or improvements
- orthoxerox 4y ago
  Yes, that's why I've written it's better to have both.
- deleted 4y ago
  [deleted]
Vinnl 4y ago
Feels like maybe a view on top your table that adds the boolean based on the timestamp might be safer, in that by definition there's no risk of the two columns getting out of sync?
motogpjimbo 4y ago
This sounds like you're opening yourself up to situations where you have rows in data_journal that have status='Loading' but which have started_loading_at=NULL, in violation of your data model. Your premise is slightly flawed in that your second example isn't actually difficult to write or understand as you claim. However, it could be argued that if the logic for selecting "loading" rows is repeated in multiple places then a layer of abstraction over it would be useful. This could be achieved in SQL by e.g. CREATE VIEW loading_entries AS SELECT * FROM data_journal WHERE started_loading_at IS NOT NULL AND finished_loading_at IS NULL or, if you have several such statuses you need to define, CREATE VIEW data_journal_view AS SELECT data_journal.*, CASE WHEN started_loading_at IS NOT NULL AND finished_loading_at IS NULL THEN 'Loading' WHEN ... THEN ... ELSE 'Some other status' END AS status FROM data_journal

hardware2win 4y ago

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 architects

CodesInChaos 4y ago
You might want to take a look at EdgeDB. You still have to define a schema, but both its data model and query language have much smaller mismatch with popular programming languages and APIs, so you don't need a complex ORM. For example it has first class support for following links (instead of awkwardly joining on foreign keys), outputting nested data and polymorphism.
onion2k 4y ago
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!"
- hardware2win 4y ago
  Even if it sounds, then what? Are you trying to say that NoSQL based systems are less reliable?
  - onion2k 4y ago
    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.

mattclarkdotnet 4y ago

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

healsjnr1 4y ago
I don't know that I completely follow on this comment, in particular how code reuse comes into it. I think the biggest thing is about deciding whether you have one or many. There are a lot of cases where having many doesn't just mean there is a list to show. In a lot of cases, having many means you now need to choose "the right one" to show/edit/action whatever. This brings up all sorts of complications beyond "just return a list instead of a single item". Even if you don't end up building it out, I think it always a good thought experiment during the design phase to think about how things would behave if there where multiple of key resources, rather than just one. Would it have implications elsewhere? Are there low cost alterations to the design that can be made now that make space / allow for this key resources to be a list later on? How hard would it these be to do later? I'm many cases the conclusion might be it isn't worth it and that's the right choice (yagni applied judiciously), but every now and again this might highlight a valuable early stage change that would have cost a lot to make later on.
- code_runner 4y ago
  I took this as “if you need more than one, plan for storing ANYTHING greater 1 or greater” Meaning that if I need to store specifically 2 addresses per user, don’t force it at the data layer… just make it an easy to swap validation and no literal limits elsewhere
- mattclarkdotnet 4y ago
  For display/view purposes, yes you need to decide what the likely option is. For model/type purposes, the decision to have a 1:1 relationship should be made only with great care, as the OP shows with the example of addresses.

samatman 4y ago

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" <-- this is wrong For the Commonweath, to whom this is no longer part of the language, "You Aren't Going to Need It" is fine, no need to include the T. Edit: I was drawing further attention to the actual grammatical distinction between "ain't" and "aren't" by showing that "ain't" conjugates the first person and "aren't" doesn't. It might help to know that "going to" is usually pronounced "gonna" unless it ends a clause, while "gonna" is more normally realized in speech as "goan". Even more: if you want to reify a partial hypercorrection, go ahead, I'm a descriptive linguist, say the 't' in often while you're at it. One of my grandfathers would have said something sounding like "yain go need it", the other "you aren't goin a need it". The latter I'm sure never said the word "ain't" in his life. Nor would he have ever spelled "going to" as "gonna", no matter what it sounds like when spoken.

BerislavLopac 4y ago
> This form comes from Britain All forms of English, ultimately, come from Britain.
grey_earthling 4y ago
“You aren't gonna need it” is ordinary colloquial British English. “I aren't…” is not.
- RickHull 4y ago
  You're not gonna need it I'm not gonna need it You aren't gonna need it I amn't gonna need it You ain't gonna need it I ain't gonna need it
  - pindab0ter 4y ago
    You'ren't gonna need it.

marcus_holmes 4y ago

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 just "can we ship the first version without it?".

scott_w 4y ago
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 either very junior or bullshitting you.
- galangalalgol 4y ago
  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, two vs many, and don't reinvent the database (or don't assume your db is flat) are effort free and always worth it. With the caveat that you maybe can't afford the overhead of a full rel db, and have to use something like an ECS for performance reasons. This is pretty common for embedded or game domains.
  - scott_w 4y ago
    > 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.

brodouevencode 4y ago

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

spapas82 4y ago

Cool list! For Django developers I've compiled a list of Django guidelines that also contains a lot of yagni exceptions especially for Django: https://www.spapas.net/2022/09/28/django-guidelines/ https://www.spapas.net/2022/09/28/django-guidelines/

BiteCode_dev 4y ago
Clicked on the link expecting to see the usual beginners advices, but I'm plaisantly surprised that I would give most of the same recommendations to my team.
- spapas82 4y ago
  Thank you for you kind words!

pindab0ter 4y ago

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

sethammons 4y ago
I've wanted to do that for a while. Look into structured logging. I want/need machines to analyze my logs, and that requires key value pairs. I put any dynamic text in its own field. "error for user 42, remote api timed out" -> level: error, userid: 42, message: api timeout, http_request: <curl call to reproduce>, timestamp: <curr_time>, time_duration_ms: 30000, ... (but as json). Now I can see what users are affected by which errors however often. Alerts are now trivial to implement. They key is being able to debug an issue after the fact. I like to include a copy-pastable curl call when I can so I can manually reproduce an issue easily as an example
- pindab0ter 4y ago
  This is great. We use Sentry for our projects, which serves the same purpose. I was wondering if using info statements in certain places are seen as a good practice, for example.
- 0cf8612b2e1e 4y ago
  The curl request log is a very interesting idea I have never seen before. Do you have a library recommendation or did you implement something yourself?

mathattack 4y ago

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.

dkarl 4y ago

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 as well. This can be a problem with hard deletes and with soft deletes. With soft deletes, well, it's hard to figure out how to actually delete things if you'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're in the same place. Maybe worse if your foreign keys are no longer an exhaustive guide to relationships. "Right to be forgotten" will be a nightmare if it hasn'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.

ainar-g 4y ago
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.
- zasdffaa 4y ago
  Can you point to an example please?
  - ainar-g 4y ago
    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 https://en.wikipedia.org/wiki/Sixth_normal_form#Examples [2]: https://www.postgresql.org/docs/current/rangetypes.html https://www.postgresql.org/docs/current/rangetypes.html

epage 4y ago

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

BiteCode_dev 4y ago

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

ParetoOptimal 4y ago

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

wizofaus 4y ago

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

worik 4y ago

"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." That is terrible advice. Relational databases are heavy weight solutions, expensive and slow. 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/or binary searching until you have a lot of (for some definition of "a lot of") data.

tantaman 4y ago
sqlite is lightweight, cheap, easy and faster than fopen :) https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/fasterthanfs.html
- worik 4y ago
  Adding dependencies to solve simple problems is foolish. I have seen many projects get bogged down in complications around interfaces to third party software. Where the 3rd party software solved some simple problem that could easily be solved in a few dozen lines of code. Databases are one of the main offenders. But command line processing is probably the worst offender I see. Simple problems should use simple problems. Most data storage problems are simple. How much code is in sqlite? I do not know. But opening a flat file, gulping in the contents, linearly searching for the blob of data you want is simple, often fast enough, can be implemented in the time it takes to find, download, install,... some package from a third party. As I said: make an interface (probably three lines of code) and put the simplest thing possible behind it. (That simplest thing will not be sqlite). If requirements expand, put something more capable behind the interface. Another thing: Most data is not relational. I have seen systems that put apache log files into SQL databases. I imagine there might be sensible uses for that, but I cannot think of any. Golly, KISS is not some random acronym written by fools. It is a fundamental principal of software design "Go straight to relational database" is not a sensible principal of anything. It is bad advice.

hbrn 4y ago

Pretty bad advice. The good thing about YAGNI is that you can treat it as dogma and you'll be fine. Sometimes you'll be wrong, but it's always going to be easy to recover from mistakes. Doesn't matter how much experience you have, YAGNI is always a net positive. Author's recommendations on the other hand require a lot of caution. Take logging for example. It's quite a slippery slope: how much logging is enough? Just a few INFO statements here and there? Or multiple levels? Centralized logging? Structured logging? Alerts? What about retention? GDPR? Good logging requires thinking. 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). 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's a good thing: unlike MAU, complexity piles up and grows non-linearly. Versioning: in most cases if you don't control both ends of the API, versioning is a requirement, YAGNI doesn't apply here. And when you do, versioning is a huge process change that rarely pays off.