
Clever ideas that failed (2010) - walrus
http://www.yacoset.com/Home/clever-ideas-that-failed
======
elvinyung
"And, behold, I will deliver you up to the programmer tendency to build
overelaborate castles of abstractions."

\--- King James Programming
([http://kingjamesprogramming.tumblr.com/post/136036727910/55-...](http://kingjamesprogramming.tumblr.com/post/136036727910/55-and-
behold-i-will-deliver-you-up-to-the))

------
nikita2206
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).

~~~
elvinyung
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.

------
dankohn1
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)

~~~
senatorobama
All hail YAGNI, the god of code.

~~~
fiddlerwoaroof
I find that YAGNI is usually used to justify hacking something together
without thinking about the design of the system you’re working on.

~~~
syllogism
Yagni is a duality though (like a trinity, but two). You've just met Yagni's
other face, You Are Going To Need It.

~~~
TylerE
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.

~~~
always_good
I don't understand. I would just about never want to use an unbounded buffer,
for example, for a channel.

~~~
ComputerGuru
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.

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

~~~
beemboy
Gotta give him credit for owning up.

------
pier25
> "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.

~~~
jorjordandan
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.

~~~
markbnj
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.

------
n3d1m
The site responsiveness is questionable. Maybe invest some time in making in
nicer looking and more responsive?

~~~
kornish
YAGNI.

