Clever ideas that failed (2010)(yacoset.com)
yacoset.com
Clever ideas that failed (2010)
http://www.yacoset.com/Home/clever-ideas-that-failed
26 comments
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 again, and it introduces a consistent delay).
It's less of a message broker and more of a scheduler, although considering that both of them have some kind of queue at its core, the distinction is probably more superficial than it seems (a FIFO job queue is basically a kind of scheduler).
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.
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.
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
https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
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.
Yagni is a duality though (like a trinity, but two). You've just met Yagni's other face, You Are Going To Need It.
An important corollary to this is "0, 1, many".
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.
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.
On the other hand, instantiating/specializing a container to hold up to 5 items can be a perfectly reasonable thing to do, depending on the application. It might be a design requirement that a safety-critical program never has to restart due to heap fragmentation, for instance.
I don't understand. I would just about never want to use an unbounded buffer, for example, for a channel.
Yes but that is an artificial limit and not an architectural limitation. i.e. a feature added to code that was once / would have been infinite otherwise.
You sound lucky, not to have tried arguing someone down from building a platform that would be able to implement both the system you're working on and any related hypothetical future systems as well.
In the beginning, KISS and YAGNI created DRY, but it was corrupted and gave birth to DIY and NIH.
> "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.
This is brilliant.
Twice is extremely optimistic though... Especially if you give it a couple of years to forget your original thinking.
[deleted]
This is why people write tests.
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 always use big words and hard to parse sentences - it's more of a display of cleverness than actual cleverness.
There's probably a specific name for this construction, but I don't know it. I'd place it in a category of statements that are not meant to be read as literally true in all cases, but use comedic exaggeration as a warning against a common misstep.
In my circle of peers, and perhaps beyond, we use "clever" as a pejorative. It roughly means what you said in the last sentence, "more of a display of cleverness than actual cleverness." In other words, calling a piece of code clever, indicates that it was made too complicated to easily grok. We also have an explicit goal of making code not clever.
The site responsiveness is questionable. Maybe invest some time in making in nicer looking and more responsive?
YAGNI.
By the time most people realize the site is not responsive or nice looking, they have will consumed about 80% of the content they will ever consume on it. No point in making it more responsive. It’s a diminished return.
--- King James Programming (http://kingjamesprogramming.tumblr.com/post/136036727910/55-...)