February 7, 2009
The introduction to Head First Design Patterns exhorts us not to reinvent the wheel:
You're not alone. At any given moment, somewhere in the world someone struggles with the same software design problems you have. You know you don't want to reinvent the wheel (or worse, a flat tire), so you look to Design Patterns – the lessons learned by those who've faced the same problems. With Design Patterns, you get to take advantage of the best practices and experience of others, so that you can spend your time on … something else. Something more challenging. Something more complex. Something more fun.
Avoiding the reinvention of the proverbial wheel is a standard bit of received wisdom in software development circles. There's certainly truth there, but I think it's a bit dangerous if taken too literally – if you categorically deny all attempts to solve a problem with code once any existing library is in place.
I'm not so sure. I think reinventing the wheel, if done properly, can be useful. For example, James Hart reinvented the wheel. And he liked it:
I reinvented the wheel last week. I sat down and deliberately coded something that I knew already existed, and had probably also been done by many many other people. In conventional programming terms, I wasted my time. But it was worthwhile, and what's more I would recommend almost any serious programmer do precisely the same thing.
But who's James Hart? Just another programmer. If that doesn't carry enough weight for you, how does it sound coming from Charles Moore, the creator of FORTH?
A second corollary was even more heretical: "Do it yourself!"
The conventional approach, enforced to a greater or lesser extent, is that you shall use a standard subroutine. I say that you should write your own subroutines.
Before you can write your own subroutines, you have to know how. This means, to be practical, that you have written it before; which makes it difficult to get started. But give it a try. After writing the same subroutine a dozen times on as many computers and languages, you'll be pretty good at it.
Moore followed this to an astounding extent. Throughout the 70's, as he implemented Forth on 18 different CPUs, he invariably wrote for each his own assembler, his own disk and terminal drivers, even his own multiply and divide subroutines (on machines that required them, as many did). When there were manufacturer-supplied routines for these functions, he read them for ideas, but never used them verbatim. By knowing exactly how Forth would use these resources, by omitting hooks and generalities, and by sheer skill and experience (he speculated that most multiply/divide subroutines were written by someone who had never done one before and never would again), his versions were invariably smaller and faster, usually significantly so.
Moreover, he was never satisfied with his own solutions to problems. Revisiting a computer or an application after a few years, he often re-wrote key code routines. He never re-used his own code without re-examining it for possible improvements. This later became a source of frustration to Rather, who, as the marketing arm of FORTH, Inc., often bid jobs on the assumption that since Moore had just done a similar project this one would be easy – only to watch helplessly as he tore up all his past code and started over.
And then there's Bob Lee, who leads the core library development on Android.
Depending on the context, you can almost always replace "Why reinvent the wheel?" with "Please don't compete with me," or "Please don't make me learn something new." Either way, the opponent doesn't have a real argument against building something newer and better, but they also don't want to admit their unhealthy motivations for trying to stop you.
More seeds, more blooms, I say. Don't build houses on kitchen sinks. Reinvent away. Most of our current technology sucks, and even if it didn't, who am I to try and stop you?
Indeed. If anything, "Don't Reinvent The Wheel" should be used as a call to arms for deeply educating yourself about all the existing solutions – not as a bludgeoning tool to undermine those who legitimately want to build something better or improve on what's already out there. In my experience, sadly, it's much more the latter than the former.
So, no, you shouldn't reinvent the wheel. Unless you plan on learning more about wheels, that is.
Posted by Jeff Atwood
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.
The main problem with Haiti’s seemingly endless misery does not lie with its deprived people desire for change.It lies with the country’s leadership and its impotent upper class.René Préval, the rubber stamp president par excellence, is governing so nonchalantly, going from blunder to blunder, that many observers concede that only Bill Clinton, the country’s new proconsul appointed by the UN, can force them into action.
You are not Alone
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.