Spence Green

Last spring I received a gift card to an ‘eMall’. The card could be used at several different retailers accessible through the eMall’s portal. These retailers offered the usual fare–electronics, books, clothes, CDs–but instead of simply directing traffic to Amazon.com or Best Buy, the mall’s designer contracted firms that were either obscure or in business solely to support the eMall. Money is money, though, so I selected several books from ‘DirectBooksOutlet.com’ (hereafter referred to as DBO) and checked-out.

My four books arrived in three packages on three different days. The first book came via the postal service and had a Buy.com invoice tucked inside the cover. Several days later, UPS delivered two books in an obviously re-used package. The Amazon.com receipt that I found inside indicated that although the vendor had made the effort to replace Amazon’s distinctive packaging, it was not fastidious enough to inspect the books. The final package, again delivered by the postal service, was the only one of the trio that bore the name of the vendor on both the packaging and invoice.

This episode was instructive on several levels. DBO is probably not a company with warehouses and forklifts, but a person who, upon receiving an order, searches for the best prices on BookFinder.com. He uses a similar procedure to compare shipping costs, and may either ship the books directly to the customer or to himself for aggregation. In some cases, this strategy may yield higher profit margins than Amazon.com’s model. But it is a solution based on circumstance, not theory, and for that reason, it does not scale. Rather than working out the complexities of electronic order processing, automatic packaging, supply chain optimization, and logistics–activities that Amazon.com engages with scientific rigor–this one-man operation chooses the assurance of immediate profits over future bounty.

The difference between these two competitors is a matter of theory. Amazon.com ran at a deficit throughout the late 90s as it sought better solutions to creating a broad product offering at minimal cost. It took a loan against future profits to build infrastructure and experiment with different techniques. It sought a theory: how to sell products over the Internet most efficiently. It was believed, but not known, that this theory would lead to profit.

DBO, it seems, chose the most immediate solution to this problem: how to make money selling products over the Internet. From this perspective, the process described above is sensible. It is ultimately unsatisfying, however, for the same reason that Samuel Langley’s flying vehicle seemed so hapless beside the Wright’s innovation: it is naive, and misses the point entirely. If a business is to grow, then its operations must scale. Even at Amazon.com’s inception, it had compelling solutions to the problems of electronic ordering and packaging. DBO’s indifference to these processes indicates an impatience that impedes the discovery of theories.

The same dichotomies are often seen in software. I recall an undergraduate programming project that required implementation of a tic-tac-toe solver. My empirically-motivated solution consisted of hard-coded rules applied to the input. In some places, my algorithms reached nine levels of indentation. On the average, my code worked, but it was neither optimal nor scalable. Later, I discovered that tic-tac-toe is a solved game, and that min-max trees can be used to guarantee a draw for any input. That implementation is more complex, though, and all that mattered to me was a decent grade, which I received. But the product was a mess cobbled together with sticks and tape, and it benefited no one.

This is not to say that sticks and tape do not have their uses. While searching for a research topic this fall, I was tempted to read and internalize every paper on Arabic computational linguistics. This project would have lasted months, with no tangible outcome. Another student advised me to choose a project irrespective of its history in the literature and burrow into it. I acted on his suggestion and started to write code. For the first few weeks, I tried to pry a theory from the data, but in the end, I collected some sticks, found a role of tape, and turned up my sleeves. Because my experience in the NLP field is so limited, the mere act of sullying my hands in this work has done much to increase my knowledge. If a naive solution can be used as an educational vehicle, then use it. If enduring success is to be realized, though, then at some point, that solution should be discarded in the pursuit of a theory. I hope that DBO has reached a similar conclusion.