Many programmers have DIY attitude. It is understandable: they want to do new exciting stuff themselves. In some cases it is perfectly reasonable: exotic functionality, special requirements, performance enhancements, and so on. Sometimes incorporating 3rd-party library makes overall API inconsistent, which is bad especially for programming tools, or big projects.

There is a fine line between DIY and NIH, when DIY part is used without rational explanations. Of course, in some cases NIH is reasonable too, e.g., high price of acquisition of required 3rd-party tools, or intellectual property concerns.

In most cases DIY and NIH are not justified. If you see something like that you may assume that developers didn’t do their homework, which is not acceptable in the Internet era. In many cases this ignorance is combined with aggressive protection of irrational decisions.

Spending years working on high-performance computer graphics I learned a lot of lessons. One of them was "structure your code as a thin layer on top of existing graphics APIs". The thinner your layer is, the faster your performance will be. Vendors spend a lot of time and money to improve graphics performance. Even if you found faster route, next vendor’s version will close the gap and leap forward with MMX, SSE, SSE2, hardware acceleration, geometry processors, and so on. The battle was lost before it started. Yet I watched in amusement how Java camp constructed rasterizers in Java and built GUI on top of them! Of course that implementation was ditched after spending years in development. Nowadays successful Java programs use GUI toolkits, which are thin wrappers on top of native GUI primitives. This is the way to go.

But history has a way of repeating itself. You can see DIY and NIH in action in different fields. Today my favorite example is JavaScript libraries. JavaScript is highly restricted language. Browser market is Balkanized and every browser is different. Even if you can concentrate on a singler browser, don’t forget that it may have and will have slightly incompatible versions. It is tempting to wrap the differences. And there are several high quality libraries, which do exactly that. Yet a lot of people are rolling out their own wrappers of XHR, their own remappers of DOM attributes, and so on. Just take a look at results of a recent Ajax Survey by Burton Group (Ajaxian has mentioned it in October along with some analysis). Whopping 40% of developers didn’t use any toolkit, 13% used "other", which means "some home-brewed library" in most cases.

If you look for Ajax libraries, you will find hundreds of them. Most of them are done by a single guy, who was assigned to do it by his professor. You can imaging what kind of code can be produced by a fresher!

In my opinion the most productive contribution to software industry is to select one of high quality libraries and improve it. What about a talented lone coder? Even a genius will reach stars faster standing on shoulders of giants.

Alex Russell of Dojo fame gives yet another example why well supported library is better than a home-made solution: Dojo takes care of fine details of platform-specific optimization.

It is nice to reimplement something in your spare time for educational purposes. But if you are set to conquer the world, it is better to do it reusing existing tools while focusing on your mission instead of mundane technical details. It sounds like common knowledge to me yet we have a lot of examples to the contrary.