A Cautionary Tale

There's a great bit of irony that pertains to us developers: six months in the lab can save ten minutes in the library. I read it recently in a new O'Reilly book, Beautiful Code. It made me think about an unqualified disaster -- and the reason for that fiasco.

In 2000, having finished a large successful ecommerce project, I was called by the CIO of Toys R Us asking if I'd be interested in heading the ongoing development of their ecommerce website. I spent about 45 minutes talking with him. During that call, I asked what their philosophy of web development was. He told me, "We believe in hiring the best developers and getting out of their way."

Hmmm. At first, I thought, "What an enlightened outlook!" but that thought gave way to another: what if the FAA took that view: "We hire the best pilots and get out of their way." Well, with the chaos that would surely ensue, I'd get out of their way too!

The job would also require that I move to New York City during the development. I declined. Lucky for me: the site melted down during the Christmas rush, causing Toys R Us to partner with Amazon.

The failure of the site was a very public black eye for ColdFusion. When they relaunched their own site, the site was written using JSP. As I understand it, the main reason for the failure came from the fact that the developers decided to load the many thousands of products into a structure, hoping to get better performance than they would from a traditional relational database. Things didn't quite work out that way.

Now, the failure of the developers wasn't that they thought of this non-traditional solution. Rather, it was that they didn't verify their idea by trying the idea out during development by loading a structure with 20,000 sub-structures, accessed by many simultaneous users and testing the stress on the server. Had they done so, they would have encountered what the public did during that infamous meltdown.

I love the fact that they thought "outside the box". But a little bit of "R & D programming" as I like to call it would have taught them what they needed to know. And the results of that testing might have led them to another outside-the-box solution: an in-memory relational database, giving them the benefits of speed they sought while preserving the integrity of the server.

The line between a brilliant and a bonkers idea is often quite fine. We want brilliance. To get it, we just need to test our ideas to see which side of that line they fall on.