|
Reinventing The Wheel Revisited
I'm reading this on another website, the context of the discussion is whether is useful or not to use frameworks:
<quote>
Avoiding frameworks and middleware can be just as important on much larger systems.
Often these frameworks ("always" in the case of middleware) will add not just overhead (latency or burnt CPU cycles) to your system, it can add complexity. When given the choice of incorporating some already existing framework, or re-inventing the wheel, I often (but not always) choose to re-invent the wheel.
See, I will end up with a wheel that I know. A wheel that spins like it should, and doesn't spontaneously start brewing coffee, because someone thought that would be a great idea.
Some are religiously against re-inventing the wheel. But hey, the wheel is a well known technology, it is not necessarily very difficult to re-invent it. This amount of work, compared to the long-term implications of being dependent on something that you do not "own", make a little re-invention here and there well worth it.
Earlier on slashdot today you saw ATMs being hit by an RPC worm. Why is an ATM vulnerable to an RPC worm? Because it runs RPC. Why does it run RPC? Well, because nobody re-invented the little wheel it would have been to do a simple data transfer over a TCP connection. No, they chose either to use RPC, or to use a significant amount of middleware which did not allow them to disable RPC (otherwise, why would it have been enabled?).
If people feared re-invention a little less, and once in a while re-wrote that darn wheel instead of relying on frameworks and middleware that they cannot possibly hope to fully comprehend, you would not have ATMs being hit by RPC worms. Ximian Evolution would not take up hundreds of megabytes of memory. Web sites would not mysteriously hang if the MS ASPX interpreter got stuck. My PHP sites would not start giving load errors on every 5% of the hits after a bad call to a file load routine half a decade ago.
The world would be a better place.
Now go re-invent, please.
</quote>
I usually try to avoid the Not Invented Here syndrome, but I've found this comment very insightful.
What do you think? What justifies the decission to use a framework versus rolling out your own solution?
Efervescent Elephant
Tuesday, November 25, 2003
First of all, a correction: The ATMs were hit by an RPC bug because they were running Windows, and Windows can't function without RPC. I don't know if the ATMs use RPC for operation or not, but they don't need to - their host O/S makes them vulnerable.
That said, read Joel's "In defense of NIH". It sums things up nicely.
Personally, I find many packages to have quality so low that I wouldn't risk depending on them because I usually can't fix them when they break.
And when you have the source, you don't need any blanket statements - you just look inside and can readily evaluate how much baggage and liability you're taking for using said framework. Then make an informed decisions.
Most decisions to NOT reinvent the wheel are, by and large, uninformed decisions. That does not mean that they are wrong - they're just based on missing information.
Ori Berger
Tuesday, November 25, 2003
I agree that it is better to write your own most of the time unless what you are using is very well known, tested and reliable - like sprintf, or strncmp.
It's different from NIH. NIH is when you won't use mice and windows because that's what everybody else is doing. The guy who rolls his own cigarettes did not invent the cigarette, he just prefers to make it his own.
Tony Chang
Tuesday, November 25, 2003
When you get that new tcp/ip replacement
coded give me a call. Ang i guess you'll
need to make your own bizzaro processor
and bizzaro OS to go with it. Then your own
bizarro language. You should be safe then.
son of parnas
Tuesday, November 25, 2003
If libraries/components/frameworks/tools/etc. were properly designed in the first place, reinventing the wheel would be less commonplace.
We've all had the experience of working with a (library, component etc.) -- and it just works. It doesn't do bizarre things, doesn't require you to jump through hoops, doesn't frustrate you with confusing side effects.
We've also had the experience of working with a (library, component etc.) that does bizarre things, requires you to jump through hoops, etc.
The latter, in my experience, is much more common than the former. So often it does make sense to reinvent the wheel. Because sometimes it's better to make a wheel and attach it to your axle than figure out make an airplane-that-has-wheels hook onto your donkey cart.
-Thomas
Thomas
Tuesday, November 25, 2003
It's not just a matter of the thingie to work or not. If it's proprietary, or open-source but not used by a lot of developers world-wide, and a critical part of your business... it might just be good insurance to write your own. Joel wrote about this before.
Frederic Faure
Tuesday, November 25, 2003
I always look for a solution I can purchase, but the reality is that I usually filter down to about 1 in 20 of what I find, download and test, and even of those that looked promising, about 1 in 5 is worth paying for.
Sometimes we'll buy a sub-standard component anyway, knowing it's not the best, but still worth the time savings -- for now. I'm certainly not against paying twice if the right thing comes along to replace the wrong thing, personally.
Even with all that, we still end up doing ourselves 50-75% of what I would expect a component company should be able to offer, but can't, because most of them just suck too badly.
Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, November 25, 2003
"We are the Knights of NIH..."
Ponty Mython
Saturday, November 29, 2003
 Recent Topics
Fog Creek Home
|
