Coding Horror started a discussion on the relative merits of writing your own code versus using 3rd-party libraries. The main argument for writing your own is borrowed from Joel’s In Defense of the Not-Invented-Here Syndrome:
If it’s a core business function — do it yourself, no matter what.
Pick your core business competencies and goals, and do those in house. If you’re a software company, writing excellent code is how you’re going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you’re a pharmaceutical company, write software for drug research, but don’t write your own accounting package. If you’re a web accounting service, write your own accounting package, but don’t try to create your own magazine ads. If you have customers, never outsource customer service.
Righty. But then why did Fog Creek, Joel’s company, build their Copilot product based on the open source Tight VNC? I mean, that is the very core of their product, and they decided to use third party code. It’s hard to think of a bigger counter-example to his claim (there are plenty of others, like Flickr using ImageMagick and MacOS using BSD code). So why the contradiction?
It turns out the quote above is naive and simplistic. Writing excellent code is not how you’re going to succeed. You’ll succeed by delivering value and making users happy, hopefully fast. Given that you have limited resources, you need to prioritize your precious programmer firepower and funnel it into those areas that will help you differentiate and build really useful stuff. Rebuilding compilers and libraries is not how you do that. Which is why Joel, who is anything but naive, borrowed the core engine of his product from VNC and concentrated on delivering smooth usability.
Thinking of “programming” as your core business function is too broad. Only a subset of your programming is truly core. You won’t do better than Prototype, jQuery, or extjs. Rails really is great, and so are CakePHP, lex/yacc, and HTML Tidy. The instinct to use third-party libraries is absolutely right. Only when the choices are truly unsuitable or inexistent should you roll your own. This is especially true now that we have so many high-quality open source libraries. Or at least you do when you’re developing in the open source ecosystem, which is something that needs to be taken into account when deciding on the right platform.
People often forget to factor in opportunity cost when thinking of tradeoffs. When you re-write stuff, not only you spent the time and money, but you also did not build something else that might have been valuable. So pick the right libraries and concentrate on giving us the goodness only you can build.