KTORIUM

Pareto

Tal Kedar — Wed, 15 Jul 2009 13:09:14 +0000

It is probably true that I could get 80% of the ingredients for these lovely lamb chops from the grocer’s right at the end of the street. That is, everything needed for the dish except for the lamb chops themselves and some decent balsamic vinegar – for those, I’ll have to travel down town. With traffic and parking, getting those few extra ingredients is, for me, more than four times the trouble of getting the rest. The same is true from the financial perspective: the aggregate cost of the cheaper 80% of the ingredients is easily less than 20% of the combined cost for the entire dish. Still… seems like there isn’t much point in cooking it without actually using lamb chops and the balsamic, right? Just imagine a bewildered Vilfredo sitting there, looking silently at me, at his plate, and at me again.

The famous Pareto principle is an observation, a fact that holds true in a great number of cases. In itself, however, it is not a strategy. What we’re really after is efficiency, maximizing ROI, minimizing opportunity cost. The relation between the two concepts is a conditional one: when it’s 80% of the potential value that can be achieved through 20% of the potential investment, we’re probably looking at diminishing returns, so it might well be more efficient to direct additional resources into other venues. If it’s 80% of anything else that we get for 20% of whatever, although the principle certainly holds, it usually would not have implications on the best course of action.

A very local maxima (xkcd)

With software projects, it is often true that implementing just 80% of the requirements yields much less than 80% of the expected business value. Assessing the value of early feedback versus the costs associated with a Patch Driven Design (PDD) approach is a complex matter, deserving a post of its own; the notion of Pareto efficiency comes to mind, where the options on the frontier represent business value optimizations over different time spans – this would make for an interesting chat over the tiramisu, I guess.

Heartbeat

Tal Kedar — Mon, 22 Jun 2009 01:01:17 +0000

A vital daemon
Eagerly pronouncing death
So it takes over

Serving

Tal Kedar — Fri, 19 Jun 2009 16:12:45 +0000

Blinking anxiously
Is this the right path?
Waiting for an ACK

The nnCoection response header

Tal Kedar — Wed, 17 Jun 2009 22:44:41 +0000

I thought I’ve stumbled on some hand-crafted response from Amazon:

$ nc -vv www.amazon.com 80 Connection to www.amazon.com 80 port [tcp/http] succeeded! GET / HTTP/1.1 HTTP/1.1 400 Bad Request Date: Wed, 17 Jun 2009 22:31:39 GMT Server: Server Content-Length: 226 nnCoection: close Content-Type: text/html; charset=iso-8859-1 400 Bad Request

Bad Request

Your browser sent a request that this server could not understand.

Note the nnCoection: close response header. The 400 response is returned, in this case, because of a missing Host request header.

Turns out the spelling mistake is intentional – Andrew Wooster’s excellent post claims that the header is changed by a load-balancing service, overriding the web server’s directive. A comment on that post identifies the service as the Citrix NetScaler appliance, and explains the logic of scrambling rather than removing the header altogether. Cool stuff.