11–20 of 27 posts
This is superb. YAGNI may have it's own Wikipedia entry, but that doesn't mean that we remember it when a brilliant idea comes to mind. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
All hail YAGNI, the god of code.
Earlier quoted context omitted.
All hail YAGNI, the god of code.
I find that YAGNI is usually used to justify hacking something together without thinking about the design of the system you’re working on.
> "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." This is brilliant.
It is brilliant... but I think it's a false dichotomy. I'm sure code can be clever and easy to debug. If it's designed in a way that is impossible to debug is it really that clever? I've been using react and redux a lot lately, and the design patterns make the code much easier to debug, and I'm not experienced enough (and probably not even clever enough) to have written them myself. It's like saying that smart people…
> "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." This is brilliant.
It is brilliant... but I think it's a false dichotomy. I'm sure code can be clever and easy to debug. If it's designed in a way that is impossible to debug is it really that clever? I've been using react and redux a lot lately, and the design patterns make the code much easier to debug, and I'm not experienced enough (and probably not even clever enough) to have written them myself. It's like saying that smart people…
Earlier quoted context omitted.
I find that YAGNI is usually used to justify hacking something together without thinking about the design of the system you’re working on.
Yagni is a duality though (like a trinity, but two). You've just met Yagni's other face, You Are Going To Need It.
Any time you are storing data, the acceptable number of items to handle are none, exactly one, or a number limited only by machine resources. Don't design a container to hold, say, up to 5 items.
Earlier quoted context omitted.
All hail YAGNI, the god of code.
I find that YAGNI is usually used to justify hacking something together without thinking about the design of the system you’re working on.
Earlier quoted context omitted.
All hail YAGNI, the god of code.
I find that YAGNI is usually used to justify hacking something together without thinking about the design of the system you’re working on.
Most of these sound awful to begin with, except the first maybe. Not to insult this guy, but people who force ego projects like these in a company quickly end up looking like a charlatan.
The first one is basically the messaging system and a smart broker. I’m not aware of any brokers that would take into account how busy a particular node (they usually just use round robin approach) but surely the concept you outlined is far from being a definition of over-engineering, cron is almost always worse because it is hardly scalable (it is with some crutches and until some point when it becomes unscalabel ag…
Spark has a scheduler that takes data locality into account (although I don't have a ton of experience with it and have no idea how well it works on a fine-grain scale). That itself is probably inspired from Borg and MapReduce, both of which have some kind of data locality-based job scheduling logic.