Never Reinventing the Wheel Is Anticompetitive
blackhole12.blogspot.com
blackhole12.blogspot.com
Given the number and quality of libraries today, one should spend very little time re-inventing wheels. I say that as someone who has re-invented multiple wheels. I wrote a clone of Ack[1]. I've built distributed data stores instead of using open source solutions like Cassandra. Even in those cases, building that software was harder than I thought it would be. Existing projects have graduated from the school of hard knocks. Time has forced them to solve issues like cross-platform compatibility, documentation, and API stability. They're certainly not perfect, but unless you're a domain expert with a lot of time to spend, you're not going to do better.
We can only re-invent so many wheels in our limited time. If you do the math, a career consists of approximately 1 million lines of code. Almost always, that time is best spent building on top of existing software.
Although I actually agree with the conclusion of this essay (that, to paraphrase, "don't re-invent the wheel" really means "don't re-invent the wheel if you're trying to invent the car"), I thought that this was really the weak point in the posted argument. Sure, if everyone wrote his or her own TLS library, then we wouldn't have Heartbleed—but instead we'd have a litany of tiny bugs leading to everyone getting exploited in his or her own way. Similarly, the advice "don't roll your own cryptography" doesn't mean that there's no room for new cryptographic schemes, just that it's a lot more likely that the bugs that your scheme would include will have been ironed out in an existing one.
Taken to extremes, the argument becomes "don't use an existing OS, because then you'll get bitten by any bug in that OS"!
P.S. Just to be clear, though I am replying to you, the arguments above (to which I suspect you are sympathetic) are rather addressed to the author of the post.
OpenSSL and other cryptography libraries are a special case - implementing your own crypto library is almost universally accepted to be a very bad idea for what should be obvious reasons. OpenSSL is used widely because it solves a problem that is best served by a universal solution - the need for standardised protocols to secure internet communications. Of course there are alternative crypto libraries out there, but it is not a bad thing that most of us rely on a single library that really is well-suited to solve this need for crypto. We benefit much more by focusing developer resources and eyeballs on OpenSSL rather than trying to diversify for the sake of diversification.
Heartbleed is a very poor example that doesn’t support the premise of this post. It was discovered, publicly disclosed, and immediately fixed because it is open source, widely used, and has so many developer eyeballs on it. This was a positive outcome to a severe vulnerability, not a consequence of failing to diversify. Closed-source crypto libraries (or any that do not undergo the scrutiny of many developers and crypto specialists) are the domain of persistent, equally severe vulnerabilities that go undiscovered and/or undisclosed, increasing our exposure to malicious actors.
For example, if you decide to create a new UI toolkit, by which I mean something that draws the widgets and handles low-level input events itself as opposed to a wrapper over one or more other such toolkits, then you need to be prepared to deal with things like accessibility for users with disabilities. This includes blind users who require a screen reader, but also people with mobility impairments who need to use alternate input devices, speech recognition, or the like. This means implementing the accessibility APIs of your host platform(s), which isn't necessarily easy. If you release an application with your own home-grown toolkit (or someone else's) that doesn't implement accessibility, then your app will be unusable to some percentage of people who need or want to use it. That's probably not too bad if you're developing a game, but is more of a problem if someone needs to use your app to do their job, take a class, do business with a particular company, or any of the other increasing number of important functions that involve software.
Or, to throw out a few other examples beyond my usual soapbox: If you're writing a new crypto library (the post did reference OpenSSL), make sure you handle side channel attacks and all the other gotchas that come with crypto. If you're rolling your own HTML templating thing, make sure it's not susceptible to XSS. If you're creating a new database or other form of data persistence, make sure the persistent data isn't easily corrupted. And so on.
Regarding the part about "most programmers", I'd venture to say that for most developers of new applications, it's best to build on proven, mature infrastructure as much as possible, and avoid gratuitous reinvention.
Got to ctrl-f to find it in the comments, but it's from here: http://scripting.wordpress.com/2006/12/20/scripting-news-for...
That's why I prefer "active libraries" [1], i.e., libraries that can configure themselves based on the needs of a consumer application. Generic types can go a long way to keep things both flexible and efficient, but sometimes the best option is to have a library generate its own code.
[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.8...
Gold.
this summed it for me : "However, if you just finished a game and think "Gee, that graphics engine was terrible, I'm going to make a better one," then writing your own graphics engine is perfectly fine."