Solving the wrong problem

Tragedy Hurricane : everybody rushes to solve the logistical and human problems related to the hurricane hitting populated areas.

My view : fuck that, let's kill Hurricanes instead.

We have many hurricanes or proto-hurricanes to test on, we have weapons powerful enough to deflect and destroy hurricanes, why the fuck are we still working in fire-fighting mode ?



(for the naysayers: a hurricane is a form of equilibrium, disrupting it in the right way will take it down without spending as much energy as the hurricane holds, current military weapons including oxygen combustion bombs are more than powerful enough, especially if used in coordinated strikes with multiple devices)

nb: I don't say we shouldn't help them, I just say preventing other hurricanes will save many more lives and should be our primary focus. - and of course there is major parallel between this and the "why don't we do anything big anymore" post linked on HN recently. Climate control has been within our reach for decades and we haven't done much in the way of making it a reality yet.

Client Side Load Balancing - it rocks

Server-side clustering and load balancing is bad mkay.

It's far too much of a shotgun approach to deliver real efficiency, and it brings its own problems (more load balancing layers, costs, SPOFs, etc.).


How about a simpler, stronger, more scalable approach ?

1. Get your server list !

• Option a)AnyCast to the "closest" server to receive the local server list (hosting on CDN is probably an option)
• Option b)The server list could even be loaded with the application
• In both cases, the list ends up cached in the application, purely IP beyond the first load

(file name = australia.global.json) 

[["url1","url2","url3","whatever"],["url4","url5","url6","other"],["url7","url8"]]

 List is of course a JSON string sorted with location (0,1,2) in order of ping distance, trimmed to needs (i.e. maybe only listing 4 servers for each secondary country instead of transferring a huge JSON file for the fun of it), pre-computed for each country and stored in the CDN.

2. Select server from list @ random

function rand(x,y){return Math.floor((Math.random()*y)+x);}//java style random sucks

var index=rand(0,jsonArray.length-1); //JS is readable. for everyone - including liberal arts ;)

var tries=1;

var url=jsonArray[index];

3. If a request fails, client picks another server and retries

jsonArray.splice(index,1);

index=rand(0,jsonArray.length-1); 

tries++;

url=jsonArray[index];

4. If three different servers from the closest country (0) fail, the app starts trying with the next one (1), etc.

If too many errors occur, the application contacts any of all the servers it knows to get a new list. If even that fails, it resorts to asking the CDN.

5. When a server becomes overloaded, it starts trashing requests on purpose

And the application retries on other servers, thereby balancing the inevitable imbalance of the probabilistic load balancing solution.

Why it's better:

Simpler, More Scalable, More Efficient, More Reliable, Better Availability - all by design (less components, no central overloaded ASIC, no server-side cluster management, no possible LB failure, potential live redundancy - i.e. API calls sent to multiple servers - across N servers).

Because failover is handled in the application itself, as long as the user has internet connection, you can guarantee 100.00% uptime (as in 100.00% of user connection uptime, the theoretical maximum anyway), without any concern for possible browser stupidity, DNS caching from browser to global server, DDoS, cache poisoning, unresponsive server that looks alive to the load balancer, overloaded servers, etc.

It enables you to deliver REAL availability to your end users because that's the only thing the failover mechanism can actually monitor.

Much better than that, with a properly designed application, the user will at most need to log in a second time  in case of failure, unless login/auth was implemented using some external service like google or facebook, in which case the failure has absolutely no effect at all from a user perspective.

Since DNS is not even used except in improbable cases (accessing the CDN for a new server list in case every single server in the original list failed to reply - something that usually means we got hit by an atom bomb, it's on the other side of the great firewall OR we lost internet connection, something that's of course checked after a few non-responsive servers), we can safely say that the following have no effect:

DNS shutdown
DDoS on someone who shares DNS with you
DDoS on anyone's DNS actually
DNS cache poisoning


And of course, it can be implemented in any web application, web site, application, mobile app, ...

Why it doesn't work like that

This solution looks so much better than what is actually being done that I expect someone to hop in at anytime and tell me why that cannot work.

So please go ahead, enlighten me and I'll come up with a much better solution then ;)

Hiring the Right People

Those who are "good" at what they do.

Part 1: why I am awesome (seriously, I rock)

I'm quite good.
Because I want to be good.
Because I cannot stand bad.

Part 2: what about the others

Noone is born good.
All the good ones became good.
Because they wanted to be good.
Because they couldn't accept bad.

Part 3: how to find the good ones

I prefer finding the bad ones, usually those that remain are quite good ;)

If they accept bad, you can be sure they're bad.
If they don't want to be good, you can be sure they're bad.
If it's both, they're really bad.

Part 4: building the test

Here, it gets a bit more complicated, because you need someone who's actually good to tell you what is bad and what is good.

That's a bit chicken and egg, but you can always ask me for IT, or spend the time to craft deep psychological tests that cover the two simple axioms I outlined above.

Part 5: How to keep your good people

We know their motivation, it was outlined above, now we just need to feed it.

Help them improve, make them work with good tools and towards good goals.

Then, pay them well (say 2 to 3 times industry standard).

If somebody "good" doesn't bring you at least 5x the value of somebody "bad", he's probably more "bad" than "good".

While this is secondary to treating them well, they have to feel that you recognize their contribution, otherwise they'll be frustrated and move on.

And most of all, don't ever ask them to follow the decisions of somebody who's actually 'bad' and doesn't want to learn (be convinced of the better alternative) - you'll piss them off and it'll end up in non-productivity or them leaving.

Your company can be the awesomeness sanctuary they've been looking for, don't miss that opportunity.

Here are two example tests, that many people will disagree with, but that are nevertheless perfectly accurate.

Example 1: MySQL

Do you know MySQL (y)
Do you use it (n)
Why (because it's broken in many ways and the advertised features aren't actually supported)

If someone says he uses MySQL, and he was NOT forced to do it, you have determined that they can accept bad.
However, they might still be pretty good, if they actually want to be good - and you should settle with that because that's still a lot better than the rest.

That's something you can measure easily, too, by presenting them with mysql's shortcomings and pgsql as a solution.
If at that point, the person says anything like "depends on use case", congratulations you've confirmed they're real bad, don't hire them.

Example 2: Apple OSX

Do you know OSX(y)
Do you use it (n)
Why (because it's broken in many ways and fuck it why can't I maximize a window, what the fuck is that moronic one-button clickpad, I'm losing productivity aaaaaaaargh) - bonus points if they're foaming at the mouth, it means their inner world is incompatible with failure, that's a guarantee of extreme attention to quality .

If someone says he uses Apple OSX, and he was NOT forced to do it, you have determined that they can accept bad.
However, they might still be pretty good, if they actually want to be good - and you should settle with that because that's still a lot better than the rest.

That's something you can measure easily, too, by presenting them with OSX's shortcomings and linux as a solution.
If at that point, the person says anything like "depends on use case", congratulations you've confirmed they're real bad, don't hire them.

This is a test for techies only - using apple products is not a relevant metric for most other fields.

Bad broken tools don't depend on use case, they depend on hospital bills.

Disk lamer

I totally forgot to mention Curiosity, but then it was implicit in the "Do you know ?" part and subsequent questions.

If you were shocked by one of the two examples, please note that I totally respect your freedom of choosing inferior tools, and am merely pointing out their inferiority, nothing more.

As everything that I write, this article *could* be completely wrong.
I just feel that it's right, and as it is quite clearly much better than current hiring processes, you should probably use my method if you want "good" people to work for you.

What Really Matters

I want to see humanity progress

There's nothing quite like a man setting a foot on the moon, the first space station, cures for cancer or the revolution of mentalities.

I want to see people become smarter

There's nothing quite like a child learning to talk, walk, read or anything.

There's nothing as fulfilling as actually making a strong impact on the world. 

And what stronger impact could one have than empowering others to make a much stronger impact.

I want to see people become wiser

Karma was understood by Jesus ("father, forgive them ... ") and by Buddha a long time ago and yet some people ignore the obvious fact that life must be respected (because we're life, duh).

Equilibrium was well understood in chinese culture (yin/yang) a long time ago, and yet most people thought it acceptable to allow large scale human activity that did not take into account the need for a complete cycle.

As a race, we must find a way to promote wisdom, or it's going to take infinitely longer for "heaven on earth".

I don't have the right solution yet, but it shouldn't take too long if we all search together ;)




and there I am, working for money so I can buy the freedom to work for those goals -- not bad but not quite there yet. Still, I think I've got a plan :)