Reinventing The Wheel
Reinventing The WheelGo ahead. Grab that chisel and start pounding. You know you want to.
An idiom common amongst engineers and developers.
Definition
Why invent a new wheel when you can walk to the store and buy one? Why invent a wheel when you can invent the engine?
Tis better to RefactorTheWheel. Just don't ReinventTheFlatTire
What programming languages do you find yourself reinventing the wheel a lot for? I don't do it much in CeeLanguage, PerlLanguage, or PythonLanguage, where it's easy to go find a wheel to take apart for pieces. However, I find myself doing it endlessly in VisualBasic. Where are the parts for VB? Comments?
Examples?
Some languages are themselves reinventions of the wheel, such as CsharpLanguage.
"Heh. CsharpLanguage is more like a reinvention of the ball gag."
Make seems to be a common target for reinvention. Witness Module::Build (Perl), rake (ruby), scons (python), boost::build (python, again), and many hideous piles of shell scripts.
If people didn't reinvent the wheel, then our cars would still be running on sawed-off tree trunks. Let us use what is already there that works, but when it doesn't work, let's invent!
When talking about software, it was FredBrooks in TheMythicalManMonth who said that people will always reinvent the wheel because it is intrinsically easier and more fun to write your own code than it is read someone else's code. -- Patrick Collins
"It's not that reinventing the wheel is bad, it's the unending discussion about whether our wheel should have three corners or four." (From a UseNet discussion about running science fiction conventions. -- David Wolff)
A lot of wheel reinventing goes on because of the NotInventedHere syndrome.
Speaking for myself and all the wheels I've reinvented, I'd say I did it mainly so I could understand wheels. Instinct told me that without that understanding, I might not survive in this (systems development) environment, in which detailed concrete knowledge is often the only real power.
People who have already learned X are often impatient with those who are still learning X, hence all the frustration over reinvented wheels. It's what happens when you compose the concepts of learning and production together in the same process.
This is why it is advisable to take learning your craft serious and have a laboratory at home where you can learn new concepts without affecting your work environment until the ideas are ripe. There are too many distractions in most work environments to do the deep thinking needed to learn new concepts effectively; half-baked is not my idea of optimal. On the other hand, there is some cost involved in building your own development environment at home; however if you are a computer geek this is a foregone conclusion.
If we're clear about when we reinvent to learn, then we can make better choices about what to do with our reinventions. Having reinvented and gained some confidence in a given area of technology, I may then decide to throw out my rather shoddy scholarly work and adopt your more polished version for actual production. This would seem to be the best of both worlds.
Some wheels are rarely reinvented, because they exist, are accessible, and they work. How recently have you felt the need to roll your own windowing system, scroll bar, combo box, etc.? I contend that VB, MicrosoftAccess, etc. support extensive re-use (e.g., building on top of MS-provided capabilities.)
We need to extend those foundation modules which are usable as-is to a much higher level, particularly for the record-oriented information systems that constitute the large majority of in-house developed business applications. (Yet another shameless plug for a DoItFramework approach.) -- JimRussell
Reusable parts without source code are hard to reuse. If they have bugs, you have to do long, expensive experiments to determine what the bugs are and how to work around them. If the documentation does not adequately describe how the components work, and you do not have source, you are once again reduced to expensive experimentation. This is why experienced programmers turn to their own components first. Not because they dislike code others have written; it is because having the source is worth a whole lot of reuse.
You can argue that the documentation could be better, but the documentation will always be inadequate (for cost, human, and technical reasons). You can argue that there should not be bugs, but there will always be bugs. The wheels best reused are the ones that you have the source for.
Do I hear a plea for OpenSource software here? -- StephanHouben
I am, as always, unable to hide my true intentions. You are correct, Sir.
I just love reinventing wheels because I need more wheels and my supplier decided to stop supplying them (i.e., writing controls that work identically to sheridans because the sheridan controls ceased to be shipped with VB5, and my company needed more licenses to VB5).
With someone else's wheel, it's very difficult to know exactly what the wheel will do under all situations. Misunderstandings of OtherPeoplesCode is the largest cause of defects and frustration. For most wheels that take less than a week to implement, ReinventingTheWheel is better than finding, evaluating, understanding, integrating, and testing an existing wheel.
Coding your own solution to a common problem that probably has already been solved. In the worst cases, it's already been solved in your language's core libraries. Other times, it may be something like everyone on the team writes there own Base64EncodeMethod or something similar because they are under too much pressure to negotiate a common module (assuming shop != XP).
Sometimes avoiding this is in direct opposition to closed source software. Their are many wheels that have been reinvented and frequently badly because of this.
Security seems to be an area of filled with cases of ReinventingTheWheel. I have encountered numerous projects where people invent their own encryption, key exchange and/or authentication schemes either because nobody bothered to check how existing protocols do these things, or existing methods are too slow, too complicated, or somehow "not applicable".
Sometimes, there are just plain stupid requirements that seems to make the system more secure, but, in the end, forced out proven freely available implementations of well-establish protocols with homebrew schemes that are unproven and newly implemented.
In one case, the customer insists that we do not use the same key to encrypt information coming from different parties, even though that's the company's public key. But they don't want to keep one key for each party (duh, adding a few hundred bytes for each party's record in the DB is too expensive? or what?). So they come up with a scheme to "generate" different keys based on a shared key plus some parameters, and the parameters are sent plain form (so they know how to get the "generated" key). But there is more, the "hosts" cannot perform decrypt fast enough (for whatever reason), so they developed their own encryption algorithm which is faster! So in the end, they have avoided existing well established protocols, to spend weeks (if not months) to implement their own (probably much weaker) encryption/decryption algorithm, and to develop their own (manual) key exchange procedures to distribute the shared key, to satisfy the above 2 requirements.
How do you ExplainSecurityToBusinessPeople?
Invention is the natural result of applying what we see around us to what we do. The ability we have of visualizing solutions to existing problems is a very important human characteristics. That solutions may occur independently and often almost at the same time is a product of this characteristic.
Well, when the same solution to a common problem emerges nearly simultaneously in many places that's not quite the same thing as what I think of as ReinventingTheWheel. It can be wasteful of resources, but that is a coordination problem. What I think of as ReinventingTheWheel is building from scratch something that is already available but for some reason is not perceived as adequate.I have a project team where one member is more prone to ReinventingTheWheel than is good for the project. My observation is that for him the driving force is to understand at the lowest level and to have control over all the knobs and levers. My challenge is to help him move to a different perspective by asking him to consider what he is missing out on. Somewhere too there is the issue of trust. By ReinventingTheWheel you don't have to trust store-bought wheels (or in extreme cases a teammate's code). Closely related is committing to a choice. Not being able to commit to a store-bought wheel leads you to invent one in the meantime. I haven't quite sorted out these last two aspects, but I can think of other evidence that trust and being decisive are tied up with it in this particular case.
At a strategic level, ReinventingTheWheel ignores the potential of RidiculousSimplicityGivesRidiculousResources by missing out on ready-made solutions available at far less cost. At the individual level, it can rob the developer of growth opportunities and lead to an outdated skill set. And at a team level it leads to an erosion of trust and potentially to missed milestones.
What some perceive as ReinventingTheWheel may in reality be that a designer or programmer sees an existing solution as inadequate and less than optimum, because it fails to utilize developing technology which will more efficiently or more smoothly lead to better results.
Why not solid rubber tires, as in the past? Why do we use wheels filled with air? -- http://answers.yahoo.com/question/index?qid=20061231145815AAjqbJ0
See also:
EditText of this page
(last edited August 16, 2014)
or FindPage with title or text search