Joel on Software at “How Microsoft Lost the API War” :
But the idea of unifying the mess of Visual Basic and Windows API programming by creating a completely new, ground-up programming environment with not one, not two, but three languages (or are there four?) is sort of like the idea of getting two quarreling kids to stop arguing by shouting "shut up!" louder than either of them. It only works on TV. In real life when you shout "shut up!" to two people arguing loudly you just create a louder three-way argument.
(By the way, for those of you who follow the arcane but politically-charged world of blog syndication feed formats, you can see the same thing happening over there. RSS became fragmented with several different versions, inaccurate specs and lots of political fighting, and the attempt to clean everything up by creating yet another format called Atom has resulted in several different versions of RSS plus one version of Atom, inaccurate specs and lots of political fighting. When you try to unify two opposing forces by creating a third alternative, you just end up with three opposing forces. You haven't unified anything and you haven't really fixed anything.)
HOW STANDARDS PROLIFERATE
(See: AC chargers, character encodings, instant messaging, etc.)
SITUATION: There are 14 competing standards.
Geek: 14?! Ridiculous! We need to develop one universal standard that covers everyone's use cases.
Fellow Geek: Yeah!
SITUATION: There are 15 competing standards.
Title text: Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit.
“An IDE that doesn't suck.” - conversation from Freenode’s ##programming chatroom.
Linas Vepstas in “Call Center, Bug Tracking and Project Management Tools for Linux:” (which is an old page that is kept from historical reasons):
Note to Free Software Programmers: Please DO NOT create yet another project to implement some system! There are too many half-finished, half-functional systems already! Do some research, find a system that is appealing, and volunteer to carry it further! At first, this may seem less rewarding, because you won't be Mr. Super-Duper I-am-Head-of-the-Project Big-Shot Might-Be-Linus-Torvalds-Soul-Brother. But in the long run, you will find much more satisfaction from working on a project that everyone knows and respects, than being the sole author of and world-wide expert on some poopoo-kaka that no one has heard of. I speak from experience!
Eric S. Raymond in The Cathedral and the Bazaar :
So, did I immediately launch into a furious whirl of coding up a brand-new POP3 client to compete with the existing ones? Not on your life! I looked carefully at the POP utilities I had in hand, asking myself ``Which one is closest to what I want?'' Because:
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
While I don't claim to be a great programmer, I try to imitate one. An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it's almost always easier to start from a good partial solution than from nothing at all.
Linus Torvalds, for example, didn't actually try to write Linux from scratch. Instead, he started by reusing code and ideas from Minix, a tiny Unix-like operating system for PC clones. Eventually all the Minix code went away or was completely rewritten—but while it was there, it provided scaffolding for the infant that would eventually become Linux.
In the same spirit, I went looking for an existing POP utility that was reasonably well coded, to use as a development base.
The source-sharing tradition of the Unix world has always been friendly to code reuse (this is why the GNU project chose Unix as a base OS, in spite of serious reservations about the OS itself). The Linux world has taken this tradition nearly to its technological limit; it has terabytes of open sources generally available. So spending time looking for some else's almost-good-enough is more likely to give you good results in the Linux world than anywhere else.
A motto that appeared on the site of CPAN, the Comprehensive Perl Archive Network:
Stop reinventing wheels, start building space rockets.
The nice thing about standards is that you have so many to choose from.