Duplication of effort, industry-wide: why?

Discussions

News: Duplication of effort, industry-wide: why?

  1. Duplication of effort, industry-wide: why? (56 messages)

    One reader mentioned having written his own HTML parsing library to handle unbalanced tags and other such HTML warts. Considering the presence of libraries like NekoHTML or TagSoup, that sounded odd: normally re-use is preferred. On asked why he didn't re-use an HTML parsing library, he responded with "I needed it in 1998..." It's an interesting (and valid) point. How many libraries are created and recreated based on things like:
    • Lack of knowledge of pre-existing work (see ROME - an excellent and successful library - whose developers didn't know about some of the RSS libraries that used similar models.)
    • Lack of broad perception - RabbIT, the project mentioned by the user at the beginning of the post, perhaps should have replaced the need for TagSoup or NekoHTML or HtmlParser.
    • Differences of opinion of how the library should work (and, perhaps, lack of modularity?) - See PIRCBot and JerkLib for examples of this.
    • The older project might not be maintained; see HSQL vs. HSQLDB (and their progeny, like HXSQL and H2), or ci-bayes and Classifier4J.
    I'm quite sure that readers can find their own examples and explanations for this kind of thing: consider Guice vs. Spring, or Hibernate vs. EJB2, Groovy vs. Ruby and/or Python vs. Java, ad nauseum. It's not my intent to take sides for any project mentioned here, or decide that Guice is better than Spring (or vice versa), for example, even though I've been involved in one or more of the projects mentioned above (and that includes both sides: the originator and the "replacement.") The point is to call attention to the observation that while DRY ("don't repeat yourself") is often seen as a requirement in a given project, as an industry we repeat ourselves all the time. That's not really a bad thing, because you can't have a "best of breed" when there's only one project in a given space, but it's also interesting how many projects there are in any given space - and it's not trivial to find them, either.

    Threaded Messages (56)

  2. ... and Howard Lewis Ship of Tapestry would always re-invent with the argument that he wants to make his tool robust enough to withstand future (r)evolution in technology. Take the example of his current Tapestry 5 implementation. Besides the existence of good IoC frameworks like Spring, Guice, even Hivemind which he wrote himself, he went on to re-invent the wheel yet again. Mostly these existing tools they claim are not good enough are open source they could grab the source and modify to suit their needs. Then begs the question, why they don't do it? Besides laziness and lack of patience to grasp those existing tools or libraries, I think there is also an ego factor playing here. Jan
  3. ... and Howard Lewis Ship
    Can always rely on some people to turn things into personal attacks. You don't have to use their software if you don't want to. Why don't you go out and do something positive with your life rather then endless whining? Have a look at what that word "positive" means in the dictionary.
  4. ... and Howard Lewis Ship

    Can always rely on some people to turn things into personal attacks. You don't have to use their software if you don't want to. Why don't you go out and do something positive with your life rather then endless whining?

    Have a look at what that word "positive" means in the dictionary.
    Man, don't be rude. I was just motivating my argument with an example, hence my mentioning of Howard. Jan
  5. IMHO re-using has higher priority than implementing a new library or APIs as long as there are no rules preventing a company from using some other free or opensource code. For the knowledge of the existence of ready made libraries, I think with the existence of Maven repos - and similar stuff - and the ability of describing artifacts and the existnce of front-ends to search through those descriptions/meta-data, this will ease finding required libraries that support a certain functionality.
  6. For the knowledge of the existence of ready made libraries, I think with the existence of Maven repos - and similar stuff -
    I very much doubt that this approach will ever beat Google for "finding a library".
  7. Have you used ROME?[ Go to top ]

    It's awful! I'm going to open source the tiny parsing library I wrote in response to it. I was able to replace all 5-6 implementation classes I was forced to code for ROME with 5-6 lines of code. My version was type-safe, namespace-aware and used xpath expressions to get the data you wanted. Yuck @ Rome.
  8. This is ass-backwards[ Go to top ]

    The question is not why is HLS "reinventing the wheel" instead of using another open source framework as the basis for his work. Tapestry has been around for, what, ten or more years now? The question is why did the JCP create the truly awful JSF spec, which has in turn spawned multiple implementations, instead of simple endorsing the far superior Tapestry?
  9. Re: This is ass-backwards[ Go to top ]

    The question is not why is HLS "reinventing the wheel" instead of using another open source framework as the basis for his work. Tapestry has been around for, what, ten or more years now? The question is why did the JCP create the truly awful JSF spec, which has in turn spawned multiple implementations, instead of simple endorsing the far superior Tapestry?
    Bruce, your comment suggests a deep misunderstanding of the importance of separating software design from implementation. HLS unilaterally and fundamentally changed the Tapestry API across versions, leaving users with little choice but to re-write existing web applications when upgrading. Since JSF is designed by contract (i.e. it has a formal specification), interfaces are well-defined and API changes are handled carefully from version to version. JSF 1.2 maintained backwards compatibility with JSF 1.1. The fact that there are multiple implementations is not a flaw in the design of JSF, but a strength. I have switched JSF implementations, and even JSF versions, and did not have to rewrite a line of code. Not happy with HLS' changes to Tapestry? Good luck finding another implementation. Please think more carefully before making comments.
  10. Re: This is ass-backwards[ Go to top ]

    The question is why did the JCP create the truly awful JSF spec, which has in turn spawned multiple implementations, instead of simple endorsing the far superior Tapestry?
    ... Please think more carefully before making comments.
    I will take my own advice here and try to address your question. I don't know why Tapestry wasn't chosen as the basis for JSF. Was it ever offered to Sun as the JSF RI? Before I started using JSF a few years ago I looked into Tapestry and found it interesting. In retrospect I'm glad I stuck with JSF due to API stability (among many other factors).
  11. Re: This is ass-backwards[ Go to top ]

    A decent and productive API is more important than backwards compatibility. Please think more carefully before making comments.
  12. Re: This is ass-backwards[ Go to top ]

    The question is not why is HLS "reinventing the wheel" instead of using another open source framework as the basis for his work. Tapestry has been around for, what, ten or more years now? The question is why did the JCP create the truly awful JSF spec, which has in turn spawned multiple implementations, instead of simple endorsing the far superior Tapestry?
    Probably for the same reason it didn't just adopt Log4j. Even the JCP has a "not invented here" philosophy.
  13. I think rewriting stuff is OK as it can make a technology evolve in 3 ways: 1. The writers of an original library may have worked with a different set of assumptions and environmental factors than those doing the rewrite. The end result is a library that is suited to a wider range of uses. 2. One man's "simple to use" api is another man's nightmare. People see things differently. Rewrites will lead to a range of tools to satisfy a wider set of people. 3. There's knowing a technology and there's "knowing" a technology. When you (re)write something, you really get to know the underlying technology, and what issues the other libraries have to handle. Even if your rewrite gets dumped, you will understand the original library far better. So I generally have no problem with rewriting stuff, SO LONG AS the aims are clearly understood, or the rewrite is done in the person's/team's on time. Kit
  14. At the end of the day a large number of frameworks is not bad, even if they are not perfect, because they point people into the right direction. Take Java Data Binding for example. About four years ago, there were various such frameworks available, none of which I would consider really "sufficient" or "easy enough" for most broad real world usage scenarios. Now there is at standard attempt around the corner for this kind of problem. Or take ORM persistence. Tempted to think that given Hibernate and JPA all would be well? I would not be surprised if out there, someone might think it would be good idea to build a ORM framework that can do real 2-PC within the framework (allow objects to refer objects that reside in a different data store). It is not at all clear that building on the existing implementations will create a real benefit. It might very well be faster and more insightful to start from scratch, the insights can be backported eventually - or if no-one is interested there might be a new framework to stay. Or another one: There are dozens of Java-XML binding frameworks but there still is none that really transparently creates XSD and XML from existing Java Bytecode. And of course "not invented here" is there to stay.
  15. At the end of the day a large number of frameworks is not bad, even if they are not perfect, because they point people into the right direction...
    Sure, as long as all those frams and libs have filled the following template and posted it on the very first page of their documentation and web site: 1. I(we) had a need to do: 2. I(we) have tried the following frameworks: before starting to develop my own 3. They are supposed to address my needs but I was not happy with them because: 4. I(we) decided not to contribute to any of the existing open source frameworks because:
  16. At the end of the day a large number of frameworks is not bad, even if they are not perfect, because they point people into the right direction...

    Sure, as long as all those frams and libs have filled the following template and posted it on the very first page of their documentation and web site:


    1. I(we) had a need to do:
    2. I(we) have tried the following frameworks: before starting to develop my own
    3. They are supposed to address my needs but I was not happy with them because:
    4. I(we) decided not to contribute to any of the existing open source frameworks because:
    To whom does the developer owe this explanation and why? If you don't want to use newer approaches because they haven't asserted their right to exist, then don't. It seems to me that this is a fairly useless criterion for choosing tools.
  17. At the end of the day a large number of frameworks is not bad, even if they are not perfect, because they point people into the right direction...

    Sure, as long as all those frams and libs have filled the following template and posted it on the very first page of their documentation and web site:


    1. I(we) had a need to do:
    2. I(we) have tried the following frameworks: before starting to develop my own
    3. They are supposed to address my needs but I was not happy with them because:
    4. I(we) decided not to contribute to any of the existing open source frameworks because:


    To whom does the developer owe this explanation and why? If you don't want to use newer approaches because they haven't asserted their right to exist, then don't. It seems to me that this is a fairly useless criterion for choosing tools.
    Well, it doesn't have to be mandatory, but I don't see a problem with those questions being answered IF YOU ARE ASKING PEOPLE TO USE OR CONTRIBUTE. I mean, in the privacy of your own office, do what you like. But if you are posting your work on TSS, you should want to justify your stuff. What problem where you trying to solve? What issue did not solve? We can then see if you agree or not and use it or not.
  18. To whom does the developer owe this explanation and why? If you don't want to use newer approaches because they haven't asserted their right to exist, then don't. It seems to me that this is a fairly useless criterion for choosing tools.
    whom: To the public out of respect to the peoples time why: to indicate that visitor deals with intelligent and smart folks who try to do something and not with clueless and enthusiastic people.
  19. To whom does the developer owe this explanation and why? If you don't want to use newer approaches because they haven't asserted their right to exist, then don't. It seems to me that this is a fairly useless criterion for choosing tools.

    whom:
    To the public out of respect to the peoples time
    why:
    to indicate that visitor deals with intelligent and smart folks who try to do something and not with clueless and enthusiastic people.
    I think it's a great idea to do these things for the reasons you give. I think we also have to face the reality that there will always reinvention of ideas because there is no way to know for sure that you have exhaustively searched the entire space of human achievement for a specific invention. And reinventing something when you are ignorant of an existing invention is often just as great of an achievement as the original, it just often doesn't provide as much value. If no one starts any new projects until they are absolutely sure no one else has done something similar or is doing so, no new projects will be started.
  20. C'mon - it is not necessary to do exhaustive search - few minutes of googling usually bring enough references to explore. Especially if starting project that takes months and years to implement. And filling in my template certainly does not prevent anybody from starting a project or reinventing the wheel - that is not the gaol. All it requires is honesty - if you start project that is direct duplicate of something simple because you do not like people running that project - state it and go for it. Whatever are the reasons - just give [all of] them and let others decide if they are valid for them or not.
  21. C'mon - it is not necessary to do exhaustive search - few minutes of googling usually bring enough references to explore.
    If that's your standard, then I agree with you. What I see (or imagine I suppose) happen is someone creates something and then someone else says "what about project X?" Perhaps the Google search wasn't using the right terms or the project was too obscure. I think it's wrong to fault someone for that.
    Especially if starting project that takes months and years to implement.

    And filling in my template certainly does not prevent anybody from starting a project or reinventing the wheel - that is not the gaol.

    All it requires is honesty - if you start project that is direct duplicate of something simple because you do not like people running that project - state it and go for it. Whatever are the reasons - just give [all of] them and let others decide if they are valid for them or not.
    We are definitely in agreement. I think any reason for startin a new project is valid other than to just steal someone else's ideas. It's up to the community to decide what's a good enough reason.
  22. Sure, as long as all those frams and libs have filled the following template and posted it on the very first page of their documentation and web site:
    You are of course aware of the fact that this would disqualify some of the most successful software products....like say projects that developed an IoC container even though one was already in existence.....also, with this mindset, why would one ever need more than one implementation of any standard? Yet there is more than one open source servlet container and I hear no one really complaining.
  23. You are of course aware of the fact that this would disqualify some of the most successful software products....like say projects that developed an IoC container even though one was already in existence.....also, with this mindset, why would one ever need more than one implementation of any standard? Yet there is more than one open source servlet container and I hear no one really complaining.
    I am wondering why Karl you think that the template promotes ONE implementation mindset. It is not the idea behind it and certainly not my mindset. What need to be changed there to convey better the idea that it is OK and fine to start new project that does exactly what another project was/is supposes to be doing as long as reasons for doing that are clearly stated and it is admitted that there is already something that does the same thing. Reasons might be IMO: better/simpler configuration, support for certain pragmatic features(setters injections ;) as referred to that ... most successful IoC), whatever actually.
  24. I am wondering why Karl you think that the template promotes ONE implementation mindset. It is not the idea behind it and certainly not my mindset. What need to be changed there to convey better the idea that it is OK and fine to start new project that does exactly what another project was/is supposes to be doing as long as reasons for doing that are clearly stated and it is admitted that there is already something that does the same thing.
    Still I don't get. Why would I need to state a reason. Might be a valid approach to start a new project in order to understand a mechanism privately. When you end up with it doing the same thing than something that already exists a very valid reason to keep it is that you understand how it works and (more important) what its actual limitations are. For a lot of open source (let alone closed source) frameworks, you will get the information "The sky is the limit". Now, do you need to publish it? Hell why not. Even if it does exactly what another project does, it might still be worthwhile to have the other project feel someone breathing at its neck. Also, do you need to be truthful? No! You need to be convincing! Imagine the Eclipse project had said: "This project is developed, because it is IBMs intention to destroy the IDE market". Probably there is some truth in it, but not very appealing. So this winds down your template to a certain specialization of: "A project that does something that an existing project does needs good marketing" :-)
  25. Or take ORM persistence. Tempted to think that given Hibernate and JPA all would be well? I would not be surprised if out there, someone might think it would be good idea to build a ORM framework that can do real 2-PC within the framework (allow objects to refer objects that reside in a different data store).
    Funny that you should mention this because I just implemented it in the Qi4j framework 8-)
  26. Has the Qi4j also a ORM component for relational databases?
  27. Common libraries often miss an extremely needed feature so I either have to join the project (if its open source) or to make my own library. Another point is that library can have a blocking bug disabling a function that is extremely important to me. Trying to learn how the library works, the philosophy behind it and fixing the bug can take much more time than to write my own library. And the last point is that library can be too huge for my small task. It can also require a large amount of extra jars to redistribute.
  28. So true, in my experience the main drives for duplication are lack of modularity (already cited) and lack of control: did you ever try to contribute fixes and/or platform support to open source projects (even apache ones?) the experience is usually less then satisfying: the project maintainers' schedules usually don't match with yours, even worst they will sometimes reject patches because they don't have time/interest in supporting a given platform (political reasons?)
  29. CPAN?[ Go to top ]

    I've always wondered why there is no Java version of CPAN (http://www.cpan.org/). Something like CPAN would make it much easier to find and qualify libraries for re-use.
  30. maven[ Go to top ]

    I guess Maven is a good candidate.
  31. Re: maven[ Go to top ]

    I guess Maven is a good candidate.
    Forgive my ignorance, but maven is a duplicate of what ?
  32. Re: maven[ Go to top ]

    I guess Maven is a good candidate.


    Forgive my ignorance, but maven is a duplicate of what ?
    I'll bite. maven is a duplication of ANT. If only I could go back in time and perform an abortion on maven, it would have saved countless people from the aweful nightmare that is maintaining maven build scripts. don't mind my rant, since I am clearly bias against maven 1.x. I still haven't decided if maven 2.x is better or a pile of fertilizer with a bow on top. peter
  33. Exactly[ Go to top ]

    +1
  34. Re: CPAN?[ Go to top ]

    I've always wondered why there is no Java version of CPAN (http://www.cpan.org/). Something like CPAN would make it much easier to find and qualify libraries for re-use.
    I wondered why too and wrote this: http://searchj.org/
  35. Re: CPAN?[ Go to top ]

    I wondered why too and wrote this:
    http://searchj.org/
    Very nice, and returns relevant results. Bookmarked! My .02: 1/ Let the community comment/rate the libs 2/ Put Ads on the site... you'll make more money than TSS. ;-)
  36. There is little in the way of non-trivial code that cannot be improved by rewriting it. If I had my druthers we'd create a new general purpose OO language to replace Java. I'm sure it would be better. The problem is not that writing new code instead of reusing old code is necessarily a waste of time. The problem is that it may be a waste of money for whomever might pay for creating the code. For the companies most of us work for, "good enough and already paid for" usually trumps "better but you have to pay for it."
  37. Yeah, it's not just software either. Look at GM, they totally started making cars when Ford already was making them. And it doesn't stop there. More recently, Toyota and Honda made cars too! What a bunch of idiots! They were all reinventing the wheel! (pun semi-intended)
  38. I just realized that we need to update the old saying "if you build a better mousetrap, the world will beat a path to your door" The new version should be "If you built a better mousetrap, what the hell were you thinking?"
  39. I just realized that we need to update the old saying "if you build a better mousetrap, the world will beat a path to your door"

    The new version should be "If you built a better mousetrap, what the hell were you thinking?"
    IMO, this isn't correct - there are lots of reasons to build better mousetraps, so to speak. Rewrites might correct crucial design flaws in other projects, for instance... or be lighter, or realtime, or have fewer dependencies, or any number of other reasons. Within scope, all are valuable reasons; it's just important to have reasons.
  40. I just realized that we need to update the old saying "if you build a better mousetrap, the world will beat a path to your door"

    The new version should be "If you built a better mousetrap, what the hell were you thinking?"
    Just to be clear, that statement was tongue-in-cheek.
    IMO, this isn't correct - there are lots of reasons to build better mousetraps, so to speak.

    Rewrites might correct crucial design flaws in other projects, for instance... or be lighter, or realtime, or have fewer dependencies, or any number of other reasons. Within scope, all are valuable reasons; it's just important to have reasons.
    I find it a little frustrating that it seems like whenever someone considering trying to solve a problem for themselves, they are attacked as 'reinventing the wheel' or 'wasting time'. I don't think that developers should try to develop everything from the ground up but there's no black-and-white answer to build vs. acquire. At my current employer, I can trace most of our problems to a simplistic buy-biased strategy. Often the reasons to build something yourself are quite nuanced and the value is not seen readily by others, perhaps because of a lack of imagination or because of a lack of understanding of the problems faced by the developer. I think it would be nice if as a community, we could give people the benefit of the doubt when they do this instead of immediately branding them as excitable novices. Maybe they won't accomplish anything novel. That's between them and their employer and/or target audience. Maybe their next attempt might change the world. I think developers should try to be more supportive of new projects and less like scolding school-marms telling kids to sit up straight and keep quiet. One last thing, one of the things that is often ignored with this is that it's not always efficient or economical to spend a immense amount of time searching for something that does what you need. If you are searching for something that doesn't exist, you'll end up needing to do it yourself anyway and all that searching is just wasted time. I'm often faced with a looming deadline and having found no suitable package deciding whether to spend another day searching or cutting my losses and getting to work.
  41. I think it would be nice if as a community, we could give people the benefit of the doubt when they do this instead of immediately branding them as excitable novices.
    It is OK to be novice, and it is NOT OK to be ignorant of previous attempts to solve the same problem.
    Maybe they won't accomplish anything novel. That's between them and their employer and/or target audience.
    Sure and we should not hear about those, but projects one wants to make public must be examined for novelty.
    Maybe their next attempt might change the world.
    There is less chance og this happening if people patted in the back for wheel reinvention. Look at scientific community: nobody applauded for rediscovering same thing.
  42. but projects one wants to make public must be examined for novelty.
    I don't think novelty is the only important characteristic. It's possible to improve on something without producing anything novel. And in my opinion, having competition in any space is a good thing. In many fields such as economics and agriculture, mono-cultures are understood to be bad as a rule of thumb. What I don't understand is why some people in the software world don't seem to see the problem.
    Maybe their next attempt might change the world.


    There is less chance og this happening if people patted in the back for wheel reinvention.

    Look at scientific community: nobody applauded for rediscovering same thing.
    I'm not asking anyone to pat people on the back for building something that provides no new value. What I am suggesting is that it would be beneficial to the community to not discourage new ideas. Who are you, I or anyone else to tell someone that what they are doing provides no value? I see a lot of projects in which I see little or no value. I might says so if asked but I would never suggest that someone not do something that they feel is worthwhile.
  43. Yeah, it's not just software either. Look at GM, they totally started making cars when Ford already was making them. And it doesn't stop there. More recently, Toyota and Honda made cars too! What a bunch of idiots! They were all reinventing the wheel! (pun semi-intended)
    +1 It is also important for me to have something to choose from. I do not mind that we have JSF, Wicket, Tapestry, Echo and many other frameworks to choose from as I do not mind that we have BMW, Opel, Ford, Mazda, Nissan and so on :) I do not want to have one framework, one language, one country) It is good that there are new implementations/ideas for old tasks. If you don't want to think, choose things that most of the people choose: JSF, BMW and USA (China?) to live in:) But lets leave some opportunities for a choice. Ideas need some space to grow and become industrial standard. Large companies and well known brands have too much responsibilities to make bold decisions.
  44. To quote James Gosling: "Often tool building is far more fun than actually doing the job at hand." We can't help ourselves... we like building things more than using things. It's just the way we are, and the result is a lot of bad software. -John
  45. The proliferation of software with similar functionality is a good thing. Without comparison, how can you know a library is the best? Without competition, can a project evolve? Nature is full of redundancy. Duplication of efforts? Not at all, it is necessary. There's another reason I think more important: The freedom to have fun. Writing software is an art. Writing code is fun, especially from scratch. You feel powerful because you have full control of your project. Ever ask why people build their own car, yard, fence, kitchen, etc? You can argue commercial vendors can do it far more efficient and cost less but you won't have the fun to make your own decision either. There are also many other aspects of starting a new project. Someone might argue that you can contribute to an existing project, but do I like the project owner, do I need all the complexity built into the software, do I like its design? And I probably can never have the same control of other people's project as my own. In terms of wasting time, many people are watching TV, are they wasting time? If I prefer writing code and have fun, I am not wasting my time. Remember freedom is much more valuable than time. Those who are screaming "Duplication of effort,..." are only focusing on monetary gains. But money is only one aspect among many others of our life! Long live freedom!
  46. Choice[ Go to top ]

    Caveat: I'll reference two of my open source projects here because they are perfectly legitimate examples directly related to the subject at hand. If you don't want to read about them, skip this post :) Sometimes folks ask us this same question of JSecurity, when asking us why we didn't go the Acegi route. Well, the answer to us was obvious - JSecurity existed and was in private use before Acegi existed, and we didn't have any other options. But in reality it is more than that because JSecurity offers what we consider major chunks of functionality that Acegi doesn't address. We also feel Acegi's way of doing things induces what I call 'cognitive friction' - thing's (to our project team at least) just don't 'make sense' like they should, and your brain hurts after thinking about them too much. It could just be a fundamental difference with how we see the world too ;) But the bigger answer really is choice. Because there is not 1:1 overlap between the two, the end-user can choose what suits them best. And functionality is only half of the reason for choice - the other half is often intrinsic - what 'feels' easier, project naming standards, configuration complexity, etc. These are all outside the realm of raw functionality, and are many times more of a deciding factor for prospective users. My other open source example is a project I just created on a whim this weekend in fact, which oddly is founded for the same exact reasons that started this TSS discussion - PojoDM: http://code.google.com/p/pojodm It is my (small) effort just to make common solutions available to the public at large. If it grows, it grows, if not, no biggie - I'll still find utility in it, and that's good enough for me. If it acts as nothing more than a collaborative medium in refining things that have been modeled over and over and over again, and people just cut-n-paste from it, it has real value. Cheers, Les Hazlewood JSecurity founder http://www.jsecurity.org
  47. Re: Choice[ Go to top ]

    PojoDM: http://code.google.com/p/pojodm (to eliminate code duplication)
    You mean like a lightweight IBM's SanFrancisco project or Oagis? http://www.research.ibm.com/journal/sj/373/rubin.html http://www.openapplications.org/
  48. I say go for it[ Go to top ]

    If you think you can do better than what is out there than I say go for it. If you can manage to get paid to do it (ethically, I mean, not just wasting your client's money) all the better. The cream will float, the junk will sink. Libraries age too, become out of style and clunky feeling. Depending on circumstances it can make sense to add a couple hundred more lines of utility code instead of adding the overhead of another jar to the pile.
  49. Re: I say go for it[ Go to top ]

    ...The cream will float, the junk will sink....
    Unfortunately shit floats too, and it stinks :(
  50. Re: I say go for it[ Go to top ]

    ...The cream will float, the junk will sink....


    Unfortunately shit floats too, and it stinks :(
    Eh, I don't see that long term (and thanks for the mental image). I think the problem you refer to is more that people get forced to use inferior libraries or frameworks, not that better solutions don't exist.
  51. It's boring...[ Go to top ]

    I think the main reason we have duplication of effort is that most developers find it boring to maintain code and more exciting to invent. And I see programming as being an art and some programmers are realists and some are impressionists and their coding styles don't get along. I often find it difficult to convince other developers to use open source alternatives and have often found it amusing during interviews how many times the wheel has been re-invented...especially when there are really good open source alternatives. Personally, re-inventing falls into 3 key categories for me: 1. Does it work? If not, how bad is it, can I fix it? ("Fix" is used loosely...could mean I just don't like it) 2. Is it overkill? (i.e. will I spend more time learning some complicated framework than I need just to solve a simple problem) 3. And the biggest - what's my deadline?
  52. Most of the time duplication (in the last 3-4 years) boils down to a mass epidemic of Not-Invented-Here (NIH) or Red-Jar Syndrome. http://www.youtube.com/watch?v=PQbuyKUaKFo (See the red jar at the end) I'm not suggesting Ruby is better, rather the java-guy's possessiveness of his 'red jar' is what I'm drawing attention to. Now sprinkle in the framework zealotry and we have the world of Java J2EE / JEE. Fun!
  53. It's called human nature[ Go to top ]

    The last time I checked humans learn by making mistakes. Using an existing tool isn't a great way to learn about the inner workings. It's only when you try to duplicate the same thing and improve on it, that you really understand it. Until human as a species becomes smart, we will always duplicate work. Life goes on, so don't let duplication bother you. peter
  54. A good balance is nessisary[ Go to top ]

    For projects that are released to the public I think they either needed to be better architected or have different feature sets than their counterparts to be worth while. In general, I think its healthy to have competing projects that approach problems in different ways.
  55. 很多东西都是有因必有果,如果只是讨论重复使用是否正确,我觉得没有绝对 答案,因为不同的人或公司有不同的需求.因人/公司而异.
  56. Many things exist due to some reason. I don't think there is a definite answer when discussing whether it is correct to reuse, since each individual or company has their own requirement, it depends on each individual or company. [This is the transalation of the Chinese post, for people don't use Chinese.]
  57. Because we can[ Go to top ]

    I know companies are always under pressure to cut costs but the simple reason for duplication is that we can. Lets face it, we have a surplus of manpower for just about any task as hand these days..... Most of the heavy lifting (manual or number crunching) is done by machines, and the people working want to do something useful and interesting as well as whatever they are paid to do. If we were constrained by some bottleneck e.g.; just had just a few computers in the world, standardization would be self enforcing as the pain of not complying would stop all but the most stubborn from developing standards solutions (that could be ran, managed etc on THE computer in a way that would cause the least pain to the computer owners/operators) This would be sub-optimal in most peoples eyes but would be the only way to actually deliver something. Duplication of effort isn't a bad thing at all. Without duplication the industry would be a much duller (and smaller) place :)