Reinventing the wheel vs. code reuse
Lately I have been marked as a ‘reinventing the wheel’ guy. I don’t object to that. After all, when I see this cool new feature, I just need to see how it was made. And since I am there, I can also test my skills and rewrite it. But is it really that bad to reinvent the wheel?
Time spent
One of the biggest arguments people use to justify code reuse is that it is done in a blink of an eye. Well, it is. You can just copy and paste the code or include a dynamic link library and you are done. Right? Wrong. Code reuse costs you a lot of time. You may not know it as development time, but as a learning curve. That is the time you will need to successfully implement 3rd party code into your application. So much for zero time spent. In the end it is up to you to weigh weather time spent rewriting the code will be shorter than time that you will use to learn how to implement the code. Be smart though. It makes absolutely no sense writing your own jQuery framework when you can get one in no time, however if you are thinking of doing an image pop-up, it is time to sit down and re-think the situation.
Less bugs
Another thing I heard a lot is that code reuse means there will be less bugs in your code. I can see how an amateur observer could see it that way. There is this code and it is bug-free code. Wrong again. Specially open source code (although vendor one is no exception) is known to not deal well with fixing bugs. Meaning, you can get a 3rd party code, implement it and then spend another 2 weeks tweaking what should be already working code. Thing is, I am yet to see bug-free software. Another thing. Someone else’s code you include into your own code, becomes your code at that moment. So think long and hard about what you will implement. After all, you might notice that your program fails as a vendor driver changes working directory each time it calls a function. This is real example btw, and I would like to see you make a smooth save from that one.
No need to know how everything is done
Fine. You maintain my code then. Impossible? Nah, just time consuming. Despite what everyone else might think, you need to know what you put in your code. Either you gain that knowledge by reading an implementation manual or by looking at the code directly is up to you. But at some point in future, a manager will locate you and ask a darn annoying question relating to that special 3rd party code you implemented and “um, that code is not mine” will hardly be an acceptable answer.
It might look like I don’t like to reuse code. That is not true. I simply refuse to implement something in my project for sheer factor that it has already been done. Thus, I usually weigh what is the fastest way to do things and then decide weather I will rewrite it or just implement something that someone else wrote. In the end, it is up to you. You are the one responsible for delivering your projects on time and for future maintenance of it.
May 12th, 2010 at 09:35
Hi
Great post.
I think reinventing the wheel makes it better. otherwise we would still drive with wooden or stone wheels 🙂
In my opinion, reinventing things leads to better code. Without reeinvention, we would still have black screens with green text on it….
June 18th, 2015 at 08:10
[…] few years ago, I wrote a post on why I don’t trust 3rd party APIs. It has never been more true than today (in days of NuGet, npm and other package managers) when […]