I find Spolsky almost entirely "miss", but then I had something of a feud with him and that colors my reading of his articles...

I think the clear thing that is missing here in this section you've quoted (and the article itself) is that if your components are properly factored, or at least reasonably factored, (whether 3rd party or internal), you can "value add" on top of the component without rewriting its source code (or even necessarily treating it as anything more than a black box). Don't throw the babies out with the bathwater, you know.

The point he tries to make with "If it's a core business function -- do it yourself, no matter what," is undercut by his over-generalization in "If you're a software company, writing excellent code is how you're going to succeed.". If you are a software company and you've scoped "write all the software" as your job then you're likely to hit a brick wall when it comes to delivery. Your value as a software company isn't in how well you've rewritten the parts of code (like say a C compiler) that you can buy off the shelf, but in getting your final product out the door. From that perspective it truly doesn't matter how much or how little your product consists of your own code versus third party code so much as the product delivers the functionality you intend it have and adds value in meaningful areas.

While the example above of puzzle-piecing a product out of a bunch of well known smaller components isn't glamorous, it gets the job done and hopefully pays the bills. Presumably if done right it gets the job done faster and more productively than your competitors that are reinventing everything themselves... Also, in the industrial world outside of software, optimizing the pieces of the puzzle is entire sets of sub-industries (such as Supply Chain Logistics) and again while that's certainly not exciting work, it can be profitable and the market is paying for those skills.

Finally, I think it says a lot that the best example Joel could think to use was an out-of-date example from a version of Excel that no longer exists built by a team that also no longer exists. I don't doubt that there is code continuity from that era, but the days of Excel being a walled garden from the rest of Office, much less the rest of Microsoft, are past... I know there are critics of the push towards a "One Microsoft" culture and elimination of some of Microsoft's worsts NIH tendencies at the cultural level, but this consumer is a fan and watching what Microsoft is doing in Open Source these days is fascinating and wonderful. I absolutely think this example Spolsky cites is dumb. If Excel's 80s C compiler was so great they should have handed it off to the Developer Division to augment or better the C compiler they were selling as a product! In this case that actually was a core competency of the company and inter-team feudalism and NIH was decreasing the overall efficiency of the company and potentially keeping useful, profitable, and marketable enhancements from the profit center that could most benefit. Really just an all around terrible example.