All things distributed: Growing (up) is hard

Werner hints that Amazon guarantees performance and availability while scaling up to handle exponential growth in data-sets and user requests successfully. He also asserts that the techniques have remained a dark art.

I don't agree with the second part. There are many out there that beat the same problem (I had the good fortune of working with one such company). Those who have won have solved the problem by creating a solution that is tailored to their context in conjunction with well known techniques for scaling and redundancy. Everyone has to start someplace, I recommend – "Programming Pearls" by Jon Bentley.

"Growing up is hard" – Werner Vogels on All things distributed.

To those who still read this blog. I am growing (up) and this blog is beginning to suffer. I am working on fixing that problem (not the part where I am growing ). Until then, thanks for stopping by.

Defining Performance & Scalability

A little surprised this has not been discussed before?

• "Performance & Scalability" – All Things Distributed.
• "A word on Scalability" – All Things Distributed.
• Discussing scalability on the server-side thread.
• "Managing a mega-service" – A conversation with Phil Smoot of hotmail.

Fuzzy Programming

Original Article: "Coding Tool is a Text Adventure" – Wired Technology News, Mar 15th, 2006.

Software developers are going to get a kick out of this new virtual programming tool:

Now, thanks to a new software-collaboration tool, you and your intrepid party of fellow hackers can navigate your labyrinth of code and slay its dastardly bugs, all in a dungeonlike world similar to an old-school text adventure.

Called playsh, the new tool is a collaborative programming environment based on the multi-user domains, or MUDs, so popular online in the early 1990s.

more… 

NullPointerException thrown

Seriously considering enforcing every assertion of the form,

String objectA = objectB.getStringValue();

Rewrite as the following,

String objectA = objectB.getStringValue() != null : objectB.getStringValue() ? "";

Advantage, you won't encounter a NullPointerException.

Disadvantage, every object has to have a default, non-null state.

Anyhow, this is not a recommended practice. In many cases, all a programmer would be doing is replacing poor code which throws a NullPointerException with poor code that will try to work with bad data (and eventually choke with unclear symptoms).

A better rule of thumb might be, if your writing a producer, never return a null object, throw an exception instead as an expression of error. If the value is a null reflecting the storage (file/relational db or something else), then it cannot be helped.

If your writing a consumer, always check your arguments, log which ones are null and re-throw a runtime exception. Unfortunately, a runtime exception can throw things out of whack. Use it judicously. If a null object can exist (see the storage case above), you may have to work around it (by applying a default code path). Even if you were to assert that the consumers arguments cannot be null, a code review would catch it, since your assertions are now explicit.

To conclude, I recommend that a consumer must avoid re-throwing a runtime exception, check its arguments, and wherever possible, explore the option of providing a default code path when critical arguments to the consumer are null. For example, if a users language and country is null, select the system default locale.