There’s probably some code out there which does what you need. It’s written in the right programming language, it’s open source, and it’s well documented. So why do you still feel like you need to write your own code? Why do you feel like you need to reinvent the wheel?
Don’t worry, you’re not alone. Programmers everywhere feel the need to write their own code even when they could easily use someone else’s code. Practically every programmer would prefer to design a system from the ground up rather than simply integrate someone else’s code.
All the programming books—and your boss—say that you should use workable pre-existing code whenever possible, but what about the exceptions? When can you reinvent the wheel and reasonably justify it to yourself and your boss?
The Inventor Of The Wheel Was A Genius
Few inventions have contributed more to human material welfare than the wheel, but somebody had to invent the wheel in the first place. (Technically, the wheel was probably invented several different times in several different locations.) That early genius spent hours, days, or years playing with round objects until he or she managed to build a working wheel with an axle.
The experience of building that first wheel made its inventor an expert in contemporary wheel building. Sure, wheel building has come a long way since then, but the act of building something yourself will always make you an expert in it.
When you reinvent the wheel, you go through most of the same steps as the original inventor. The only difference is that you know the end result is possible. But whether you invent or reinvent something, you end up knowing much more about it than anyone who merely uses it.
Creating your own version of an existing library, framework, or other system has a lot of pitfalls, but it has one huge advantage: you will understand and appreciate those existing systems much better than the programmers who never looked at the internals.
Inventing The Wheel 2.0
Reinventing the wheel gives you a chance to improve it. Think about ancient wheels made out of sawed-up logs versus a modern bicycle wheel which can hold over 150 times its own weight using tiny tensioned spokes. Both wheels perform the same function, but they have practically no technology in common.
When the current technology doesn’t fulfill your needs well enough, or you see an opportunity for improvement, it’s time to reinvent the wheel. But be careful—success comes with a price. One of the advantages of using someone else’s code is that they do most of the work to maintain it; if you write your own code, everyone will expect you to maintain it.
The best solution, when it’s available, is to contribute your improvements back to an existing open source project which will do most of the code maintenance for you. Even better is convincing them to support you from the start as you design and implement your improvement. You get the same result, but you may only have to do a fraction of the work.
Don’t let anyone systematically tell you to never reinvent the wheel. Sometimes the extra cost of doing things yourself is worth the benefits of improved skills and better features.