I had two interesting tabs open next to one another, and their proximity got me thinking.
One was Rico Mariani, who’s a developer at Microsoft, and an avid performance blogger. I read this post years ago, and bookmarked it, because it’s always struck me as strong evidence for using the best tools available to you. Rico’s post is about a competition with Raymond Chen, of TheOldNewThing, to write a dictionary application of some sort. To make a long story short, Chen worked in familiar C++, and Rico used C#, which was relatively new, and the .Net libraries were still somewhat unproven. Popular belief was, and often still seems today, that C++ and native code will always outperform “bulkier” frameworks with memory management abstracted away. Needless to say, the first version of the C# program slaughtered the first C++ code that Chen wrote, by a factor of nearly 11 in execution time. In fact, Rico finished his program the same day as Raymond, and Rico didn’t spend the next two weeks rewriting the algorithm a total of seven times. But the unmanaged, supposedly “faster” code was outperformed by Rico’s first attempt until the fifth version of Raymond’s code. When Rico changed a few things in the C#, it took him less than an afternoon to shave another ~30% off the execution time, because, he says, he hadn’t even really optimized it in the first place. This new version still works only-a-fraction-of-a-second-slower-than the seventh and final iteration of Chen’s C++ implementation. I might have messed this story up a bit from memory, but the point is the same, paraphrased as my own personal twist on a Knuth quote- “Writing your own optimization is the root of all evil.” Ideally, you should use the framework for that — you know, the one that already works?
And the other article came up on my Twitter, a repost of Mark Andreessen, who’s basically akin to a Norse God on the internet. This post is literally about how he invented the <img> tag, but drives home a stronger point- that the <img> tag exists because that’s the code that shipped. For all the other companies trying to build what would eventually become a web browser, back in 1993, and for all the suggestions on the www-talk mailing list, Mark Andreessen was the one guy who wrote code for Mosaic that actually added image support. Everyone else had ideas, and most of them were great. Some people foresaw things like image interactions, or line drawing. One guy suggested an <audio> tag, which just got implemented in HTML5. Mark himself said he’d support “MIME, maybe, someday”, but apparently never got around to it. None of these people, from what I can tell, actually wrote anything. Mark wrote it. The code that shipped just worked by simple support for an <img> tag, with a src=”" attribute, which is how it conventionally remains today.
And so I deduce from these posts: Good software is software that has been written. Bad software is software that has not. The dangers of using cutting edge code are well documented; the benefits of using the latest tools are not. You should always (usually… probablly…) use libraries, platforms and tools that other people have tested and used, where it makes sense, it will probably get done faster, and run faster, and in the event that it does not, you can rewrite a component for speed. The important part is just getting the first version to work.
http://blogs.msdn.com/ricom/archive/2005/05/19/420158.aspx
http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element