WHY I LIKE REINVENTING THE WHEEL
There are certain philosophies in application development, and coding in general, which are quite fashionable these days along the lines of: Don’t Repeat Yourself (DRY), don’t build it until you need it, and don’t reinvent the wheel. Actually, I really agree with the DRY approach. I think “don’t build it until you need it” is a good approach a lot of the time, but sometimes there’s something to be said for “just build it right the first time.” Those are both topics for another post. The that resonates the least with me is “don’t reinvent the wheel.”
The idea behind “don’t reinvent the wheel” is two-fold. First, it’s a time-saver. If someone else has already done it, you can leverage their hard-work and spend your time on something new or more profitable. Second, is that it helps separate you from ego. Joel Spolsky describes the duct-tape programmer. This is someone who, while a very strong programmer, and highly capable of sorting out hard problems, isn’t afraid to do something a little more quick-and-dirty when appropriate. A programmer who embraces “don’t reinvent the wheel” is one who doesn’t want to write a whole new language just because he can and because he thinks it would be cool. Both of those are admirable and valuable reasons.
I think there are a few reasons to not always be spoon-fed that philosophy, however.
The #1 reason I am sometimes wary of using code or widgets someone else has written is that it so often becomes a coding, troubleshooting or maintenance problem. I find that more often than not, I end up needing to alter someone else’s work. Sure, contributing to an open-source project can be good for everyone, but it terms of pure hours spent, it’s usually a lot easier for me to write 500 lines of new code than update 100 lines of someone else’s. Then, when there’s a bug to troubleshoot, it’s now a lot easier for me to make sense of my new code than that other person’s (if it’s even open-source). The worst case scenario is that you grab someone else’s code, struggle to bend it to your needs, limp along with it for a while, and then end up writing something from scratch anyway. Now, all that time working with the other code is effectively wasted. There’s a balance to be had, obviously. For me, there’s some combination of how hard something is to do, and how well established the other code is, that makes it far more obvious not to reinvent the wheel. jQuery is an example of that. DOM manipulation, AJAX, and animations are all things that are hard to get right, and jQuery (and other similar JavaScript libraries) have invested a lot in being really good at it. I don’t need (or want) to reinvent that wheel.
Another concern using pre-existing solutions is the danger of mediocrity. In an attempt to save time and money, it’s often so appealing to developers and managers alike to buy a canned solution. Sometimes that’s the best decision; especially when the service it provides is not a core part of your business. My philosophy, however, is that to make great applications, you have to continually ask the question, “how should this be done?” It’s not just about the shortest path from A to B, or slapping something together to make a buck. If you really stop and think about the best possible user experience, it’s very likely going to require you to build something custom. When I see the same old widgets or UI frameworks from one app to the next, I always think, “there’s another app with no creativity.” And more often than not, they have a business model to match.
Truly remarkable stuff is new. I know it’s cliche to say this, but we have iPhones because some developers and designers decided it wasn’t good enough to marginally iterate off of what was existing. Most of the great products and apps I admire all have that in common. While everyone else was trying to bootstrap off a bunch of cheaper, already-done solutions, they chose to be uncompromising about making something great. Why do the rest of us not feel we’re good enough for that approach?
The last reason I like reinventing the wheel, though, is that it’s purely a personality thing. Different developers code for different reasons. For me, it’s a creative exercise, and it’s fun (see: not a duct-tape programmer above). I like to really work out ideas, and most of all, I like to make things. And, that’s going to continue to mean that I try to reinvent the wheel to see if I can make a better one. If nothing else, I’ll learn a lot from it.
