This is an important point to understand. Otherwise you will grow up to be one of those curmudgeons who refuses to comprehend why all the kids today insist on reinventing your language of choice, only with a different syntax, a slightly different subset of the features of Common Lisp, and kernel-level support for Twitter. (Which is crazy, since Twitter is just a fad. We had IRC back in 1988! Grumble grumble grumble.)
The way to understand things is to take them apart and put them back together, repeatedly, preferably with slight variations each time. It was true with the wind-up alarm clock I had when I was a kid, and it's true with software, today.
Of course, you do have to be careful. The CW cautions you against reinventing the wheel, not because rebuilding something isn't the best way to understand it, but because many programmers consistently overestimate the utility of understanding something as opposed to merely shipping it and moving on -- or just skipping it and buying an off-the-shelf solution. Our personalities tend in this direction and have to be watched. A year or two ago I spent valuable hours figuring out how to configure a local Linux mail server to handle encryption. The resulting solution worked, but I feared it was a bit delicate. So I slapped myself on the head and started paying $30 per year to Fastmail. (Which has apparently since fallen to $14 per year. And, of course, Gmail offers much the same for free.) I don't have to understand mail server configuration! That knowledge adds nothing to my life!
"many programmers consistently overestimate the utility of understanding something as opposed to merely shipping it and moving on"
I agree and want to add that it's not just overestimating the utility of something that is a problem but underestimating the quality of something because you did not write it. Of course that can really be true sometimes but more often not. You need to investigate and make the decision process more fact driven.
I do disagree with that statement in the case that you're just plain interested in something: no reason not to satisfy your curiosity if you have the time. You will probably learn something even if it is not the most practical thing in terms of the here and now of your project. The latter is what I thought we're discussing here though, the actual practical things to do under time pressure.
I did a bit of wheel reinventing today, for one of my personal Canonical Black Holes Of Developer Time examples, too: I wrote a shopping cart.
I really, really did not want to do this -- that is why I've been using somebody else's shopping cart for the last two years. But there were two outstanding usage niggles with their cart, and my intuition from previous A/B testing is that these two niggles were going to cost me a few thousand dollars this year.
So I specced out a pretty minimal replacement -- take open source library A, write a very little connecting code, hook into shopping cart service backend B, get done in 2 hours. Of course it ended up taking 8.5, and I've still got one bug from myself, one bug Javascript bug in Firefox 3, and one apparent bug in either the shopping cart service or Google Checkout itself.
Bah.
But, on the plus side, the new cart looks great, provides for a much better user experience, and is bugs-in-your-teeth fast compared to the old one. After I get the code a little cleaner I'll write up the design rationale and how I went about building it -- maybe somebody can save themselves an hour or three that way. Because just because we have to reinvent the wheel doesn't mean we have to reinvent the spoke, too.
I don't think "critical" is the right word. Every single software layer you build on top of is "critical" (down to the OS doing malloc and threads correctly, etc). If something is both critical and already pretty bulletproof, it does not make a lot of sense to go there.
I don't have any generalization to offer, I personally make the reuse-or-build decision on a case by case basis.
There are a lot of factors (assuming it's something that is really a fit or near-fit in the first place):
- the scope of the library in question (feature set can be both too small or big, it depends on the situation if either of these things is a problem)
- the maturity (age, testing in place, testability)
- the subjective reputation/community factors can play a role
- the amount of time you have vs. the costs of implementing (duh)
- usually the licenses present a problem
- the depth of understanding I want/need to obtain (an important point that the article is touching on)
"Critical," to me, means "what your clients/customers are paying for," or perhaps "what you're competing on with those in your product space."
Facebook's critical features are the friend network, the information page, and the wall. Facebook would be stupid to write their own HTML rendering library. They would be stupid not to make sure they have the optimum data structures and indexes underlying their relationship graph, and therefore probably wouldn't use an off-the-shelf FOAF library.
My wheel may not fit your hub. While I agree that rebuilding systems is a bad idea, it's also very difficult to get every square peg to fit in the square holes we intend to put them in.
One of the bigger problems that could be solved now -- is coming up with a system that gives programmers more insight or code when they are working on a given problem. Until now, it's a crapshoot trying to find, say, a jQuery module that does tooltips in the way I need them displayed.
One of the main reasons I want to use as much library/finished code in my production projects as possible is not just that it's faster to integrate a finished code, but that there's an unknown X in for every new line of code you write and that is how many weird bugs might come up, and how much time that will cost to fix.
But then. OTOH, if you never try to reinvent the wheel you cannot judge between wheels very good either.
To futher contort the analogy: You're not reinventing the wheel; you know its supposed to be round an roll. Instead, you're changing all the internals to be a better fit for what you need. Wagon wheels are different from bicycle wheels, which are different from airplane wheels. All have a special set of characteristics, but everyone that made one didn't invent the "wheel" from scratch.
I like reinventing the wheel. If someone makes a good wheel, it's not much fun or educational to just say wheel.roll();
It's much more interesting to write it and work through the issues. Guess it depends on the context, if you just need a wheel to roll vs if you need to know how it works.
I think people should be encouraged to reinvent wheels. Sometimes it's the firm foundations of something that everyone takes for granted that need to be questioned and reexamined.
The way to understand things is to take them apart and put them back together, repeatedly, preferably with slight variations each time. It was true with the wind-up alarm clock I had when I was a kid, and it's true with software, today.
Of course, you do have to be careful. The CW cautions you against reinventing the wheel, not because rebuilding something isn't the best way to understand it, but because many programmers consistently overestimate the utility of understanding something as opposed to merely shipping it and moving on -- or just skipping it and buying an off-the-shelf solution. Our personalities tend in this direction and have to be watched. A year or two ago I spent valuable hours figuring out how to configure a local Linux mail server to handle encryption. The resulting solution worked, but I feared it was a bit delicate. So I slapped myself on the head and started paying $30 per year to Fastmail. (Which has apparently since fallen to $14 per year. And, of course, Gmail offers much the same for free.) I don't have to understand mail server configuration! That knowledge adds nothing to my life!