Why reinvent the wheel?
Why indeed? I'm not a big fan of the question, "Why reinvent the wheel?" It's what you call an Appeal to Tradition, "a fallacy that occurs when it is assumed that something is better or correct simply because it is older, traditional, or 'always has been done.'"
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?
7 Comments:
Dare I ask who/what prompted that post? I certainly hope that it had nothing to do with spring v. guice...
hi there,
sure, people bug him about why guice (when spring and others are around).
Also, saw his comment on another blog about java logging wrapper (re) invention.
As long as new inventors create sufficient documentation for guys to pick up, I'm fine. But if you come out with something new but don't have enough doucmentation, then that attitude sucks.
BTW, guice has enough documentation :-)
BR,
~A
http://anjanb.wordpress.com
This really is a general sentiment. Guice vs. Spring. Java Modules vs. OSGi. Relational databases vs. everything else.
I do think creating new logging APIs with the intention of abstracting your logging implementation is silly. That's not just reinventing the wheel--that's solving the problem the wrong way. All existing logging implementations already abstract you from the implementation. That's the whole point.
It seems to me that you should just write a log4j appender which forwards to java.util.logging, and be done with it instead of creating yet another API. Then, you could even use log4j and java.util.logging in the same application.
That cliche gets used a lot in software because people often re-invent something without knowledge of its prior existence.
Dev A: "String concatenation can be really inefficient. I'm going to write a mutable String class."
Dev B: "Um, StringBuffer? Don't re-invent the wheel!"
Dev A: "Oh right... But I want a mutable String class that doesn't require obtaining a monitor lock when mutating."
Dev B: "Um, StringBuilder? Who hired you again?"
This got me to thinking, what if the wheel was never reinvented? What would I be driving?
I agree with your said points. However, "reinventing the wheel" gets a bad rap in software engineering because many people tend to reinvent things that are completely unrelated to the business values of the company, either directly or indirectly (ie: making a framework to improve the core business value).
The concept of reinventing isn't bad but the rational/motivation behind it can often be very irrational. For example, it's like starting a flower delivery business and then getting distracted designing and building your own delivery trucks because the current ones aren't up to your standards - maybe, but you started in the flower delivery business and now you're distracted by other things that probably won't affect the bottom line of your business.
(I love Guice, btw! Keep up the good work!)
Why reinvent the wheel is valid if you are indeed just reinventing the wheel...
If one is making a better wheel then it falls under inventing a better wheel.
Additionally, putting bells and whistles on an existing wheel is not inventing a better wheel but just making the wheel better haha...
The questions about Guice then are: Is Guice reinventing Spring?, is Guice inventing a better Spring? or could Guice have existed as bells and whistles by extending Spring?
Post a Comment
<< Home