@otherguy - that’s exactly what I’m currently doing in my spare time. And yes, I do it because I like to learn how JPEG works, not because I need a JPEG decoder.
The flip side of third party code is that it can work well 95% of the time, but the 5% of the time it doesn’t work can soak up 95% of development time. This can be due to actual bugs, gaps in functionality (something you think the library ought to do, but doesn’t), or my favorite, unstated assumptions about input or program state that are not covered by the documentation and cause apparently valid code to fail.
So when deciding whether to reinvent the code or not, it’s a question of how much leverage you get (time invested vs time saved) and whether the time spent / pain endured of debugging other people’s code is less than that of debugging your own.
Of course, rewriting things for fun is its own reason. And also you should write your own code if it is central to your business or product. If you outsource your core code, you are not longer building your own product, you’re just customizing somebody else’s product and lose any competitive advantage that goes along with having your own code tuned to your needs. This goes for both proprietary and open source applications.
Your implementation will probably stink. If you are talking about Open Source libraries, they have been honed by hundreds of users over time and architected by people who are experts in their fields.
Um, that’s not always the case. Yes, the Linuxs of the Open Source world have a bunch of contributing developers (less than you’d think actually, the number is in the 150 range IIRC), however there are those projects out there created by 1 or 2 people that for one reason or another get put into mainstream. Folks who come along and use it later can and usually do discover numerous bugs in said project.
What I’m saying here is that what happens when you’re one of those experts in your field and you’re working on a project that hasn’t been honed yet?
I think the real key to all of this is knowing when it’s time to reinvent the particular wheel you’re using, or at least when it’s time to tear down the wheel and rebuild it from scratch.
The attitude of meh, it’s good enough will swim up and bite you in the ass every time.
I posted something similar to this on my blog. Rather than use libraries all the time, I frequently write redundant methods. I see it as a way to expand my skill-set and become a better programmer.
As much as I like efficiency, I like my pride more.
It’s when we as developers stop knowing how the wheel even works, that we start going downhill. If you want to understand something, try building it. I’m not saying go with it afterwards, but without that knowledge can you even truly appreciate using that design pattern, that framework, that fill-in-the-blank? Speaking of course for myself, I can’t.
Applies to everything for me. I don’t yet (well there are some exceptions that I have gone through) have an excellent set of tools (not speaking about programming tools but physical tools like screwdriver, saw, drill, etc.) - actually have really crappy ones. When I reach the point of really knowing how crappy they are, i can then rally value and cherish having a really good set.
I finally reached the point of buying a variable-speed drill + screwdriver - wow it’s nice to have! I don’t want to buy sod, let me cut my teeth and try to grow my own grass. I don’t want to buy something new, let me first buy something used and try to fix it up. I’m sure one of these years I will learn the value otherwise, but until then, I’m up for learning a thing or two.
It really comes down to: Reinventing the wheel is bad, unless really knowing that much about wheels is more valuable to your project than just having a wheel.
Software development is given a lot of different analogies, one of which is often that of a craftsman or carpenter. The techniques of carpentry have been refined and improved over thousands of years. But a carpenter, facing a new project such as a bookshelf, has to take that knowledge and apply it to a physical piece of wood. This is not as true in software engineering, where the knowledge of a thing and the thing itself can be wrapped up in a package and shared across projects.
I always thought it’d be neat to tstart with a project, such as a chess simulator, and write it from the ground up. The ideas for algorithms could come from other sources, but the actual work would be done by hand. This project wouldn’t ever really have an ending point; as you learn better and faster algorithms you could apply them back to your code. Kind of like a car enthusiast tinkering with his Mustang on the weekends, trying to eek out the last bits of speed.
This type of a project would also help with learning new platforms. Want to build an iPhone app? You could take your core chess program, expose it as an api, and then build an iPhone app that queries the api.
I agree that the best way to learn is to try something that has already been done.
I created a Notepad clone in .NET that both works tabbed and as a Multiple Document Interface. In a couple of hours, I learned a about working with GUI front-ends, opening files, saving files, closing files, pre-print processing, passing objects through the constructor, overloaded constructors, etc… It was one of my first .NET projects and in the 4.5 hours it took me to write it I saved probably 20 hours of reading books and studying examples on the web. Not to mention that I reused 90% of the parts on a future (and paid) project either directly or as more advanced features (hardcopy to file, print screen to printer, post image processing to create inverted gray-scale, etc…).
I’m a firm believer in having my own collection of programs that are diverse and interesting to me. I use them to learn and discover the features and capabilities of each language and later as references when I forget exactly how something works. Modeling it after an already existing program or concept is like skipping the specification phase because it’s already easy to visualize the implementation. If you extend it and make it a lot better than the original, it may become good material to spark an OSS project. Without that concept there would be no Winamp, no Notepad++, no Songbird, no Juice, no Miro, no Firefox, etc…
It really comes down to: Reinventing the wheel is bad, unless really knowing that much about wheels is more valuable to your project than just having a wheel
you can reinvent the wheel like the latest inventions have reinvented it. There are triangular wheels and square wheenl but the only difference is that they are on robots and they have strips of metal chainmail surounding them.
The key thing is that every coder should know how to create a wheel. Because if they don’t understand the concept well enough to re-implement it, how can they understand it well enough to build more complicated things on top of it?
Jeff ended his post with:
So, no, you shouldn’t reinvent the wheel. Unless you plan on learning more about wheels, that is.
For me, that’s the point. Anyone who cares about coding as a craft (which I do) will go and re-invent wheels on the basis that the exercise makes you a better coder. Occasionally you even come up with a better wheel, but for me, that’s not the primary reason.
I’ve always hated that particular cliché, not only because it discourages potentially useful endeavours, but also because the analogy is completely and unequivocally wrong.
The wheel is not an implementation, it’s a concept. Creating a new implementation is not reinventing. And in fact, we re-implement the wheel all the time; bikes, cars, trucks, luggage, dollies, wheelbarrows, robots, and office chairs all use completely different types of wheels with completely different specifications. We would not have gotten very far as a society if all of these designers had said, oh, we don’t need special wheels for this, we can just use those big stone ones.
This is the biggest difference between engineers and so-called developers. Engineers believe in specifications: what exactly do we need this component to do? If something actually meets the spec fully, then you buy. Otherwise, you build your own or you re-evaluate the design for appropriate trade-offs. You never, ever just look at the glossy brochure and say oh, that one looks good, let’s use that.
A great thread of comments!
The forgers of great wheels aren’t the folks who do what it takes to get the vehicle rolling and then move on. Nope, the master wheel makers are the ones who look at what they (or others) have done and bring it to the next level. I agree with the commenting this is 80/20 all over again.
And though the real focus is personal/academic satisfaction around much of this it naturally boils over into our day-to-day.
I can’t help but notice that if git’r done asap and don’t worry about building a rocket is what drives you then there are going to be a bunch of cheap quick and dirty solutions in your code. (And quite often no one is really going to understand the logic behind half the crap you pull in with the solution)
…I’m so sick of sick of supporting 10 cent wheels that you can’t get tires for…
and best of all… I can now get a chuckle when I hear We shouldn’t try to re-invent the wheel
Thanks for the read Jeff… and all your loyal readers/commenters.
I was attracted to this post because in many software development environments, designing custom code is expensive and risky as it’s lack of maturity and support-base introduces a potential plethora of bugs and suffers from low maintainability (due to its esoteric nature).
In my own career I have been blessed with a good balance of freelance and corporate experiences that have helped me determine a focused plan of action for the career long-haul. Building any kind of custom code, libraries, or widgets, no matter how faster and more efficient risks getting you canned from your job especially if your role is clearly defined.
The alternative is to plow your own field and re-invent the wheel to your hearts content for your own innovation and your own venture. For almost two years now I have been working on an ambitious project that bridges software technology with another scientific discipline. As a result, I’ve not only had the rewarding experience of gaining half an undergraduate’s degree worth of knowledge on the scientific discipline, but I’m also making substantial progress on a truly gratifying and niche product that I can call my own.
Last night I had a two-hour telephone conversation with a friend who has invested a great deal of his energy helping me with this project. We cut the phone call short as there was no end of things to discuss and it was getting late. We covered technology, algorithms, marketing, future products, and even the guiding philosophy behind all of it. Plowing your own field is exciting and invigorating, and although lacks financial security, often such security is delusional anyhow (but that’s another discussion).
In summary I would argue that re-inventing the wheel is not only beneficial, but it is essential if you are plowing your own field. There is nothing new under the sun anyway, so re-invent away, and as long as there’s a new spin on it, people will buy it and try it. But if you are re-inventing the wheel or writing a certain level of custom software for someone else where your presence is transient and impermanent, you introduce significant risk to the company as the only human being who understands it well enough to maintain it or even leverage it.
A complex software project (one with many components/interfaces owned by more than one party) has a lot of “moving parts.” It can be a real pain in the neck to keep track of them all. I try to minimize moving parts as much as I can.
If you are using time-proven library that has had very infrequent revisions and is understood by everyone in your area of expertise-- for example, the .NET CLR-- and it has exactly the function you need-- I’d use it.
But if you are considering an odd-duck third-party library that nobody has heard of, that changes often, or requires some special configuration or workaround to do exactly what you want, you are just making things more complex by using it. And later, when you upgrade or deploy to a slightly different environment, you might find that it breaks-- and that nobody really knows how it works.
Don’t re-use others’ libraries just because you’re under the impression it will save you work-- sometimes it can actually increase work in the long run.
I’m not much of a programmer as I am more of a researcher in history photos. What’s on my group’s mind is “who is that kid with the square wheel?”