
Never Reinventing the Wheel Is Anticompetitive - blackhole
http://blackhole12.blogspot.com/2014/11/not-reinventing-wheel-is-anticompetitive.html
======
ggreer
Is there any take-away from this rant? I guess I could have dodged heartbleed
if I'd written my own TLS library and avoided any software that depended on
OpenSSL. Considering the effort involved, I think I'll take heartbleed and
rotate my keys.

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.

1\.
[https://github.com/ggreer/the_silver_searcher](https://github.com/ggreer/the_silver_searcher)

~~~
JadeNB
> I guess I could have dodged heartbleed if I'd written my own TLS library and
> avoided any software that depended on OpenSSL. Considering the effort
> involved, I think I'll take heartbleed and rotate my keys.

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.

------
romanovic
I also do not see much basis for the opening statements, as written. Which
individuals or communities are pushing the dogma that you shouldn’t write
anything yourself? I’d be interested to know where Erik has met resistance
when writing software specialised for his set of problems. Anecdotally, this
is the opposite of my experience as a programmer.

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.

------
mwcampbell
This rant makes some valid points. But if you decide to reinvent a wheel, you
should be fully aware of what you're getting into, and the responsibility
you're taking on.

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.

------
api
Agreed, and then some. I don't think it's always bad to reinvent the wheel --
especially if the wheel as it exists today is wobbly, flat, or square.

~~~
cheepin
"The good thing about reinventing the wheel is that you can get a round one."
Douglas Crockford

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...](http://scripting.wordpress.com/2006/12/20/scripting-news-
for-12202006/)

------
amelius
> then I invite you to put monster truck tires on your smartcar and tell me
> how well that works

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...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.8031)

------
romain_dardour
It we never reinvented the wheel it would still be made of stone.

------
ezl
> _Including the entire jQuery library just so you can have the $( "id")
> shortcut is like driving a smartcar with spiked monster truck wheels down a
> freeway. It's dangerous, stupid, and completely unnecessary._

Gold.

~~~
andyidsinga
yup!

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."

------
mistercow
This article fails to take forking into account, which I feel largely
nullifies its point. I'm not saying that reinventing the wheel is always bad,
but to leave out forking is to construct a pretty weak straw man.

~~~
EugeneOZ
Actually article contain argumentation that forking can't save software if
this software was designed wrong.

------
LukeB_UK
I have no idea where he gets the basis for his first couple of sentences.

