Don't Do It Yourself


News: Don't Do It Yourself

  1. Don't Do It Yourself (11 messages)

    I saw a conversation on IRC today that really surprised me. Basically, it went like this: guy comes in, and says "I need to write a library for service acquisition, so I can get a service with something like getService(PersonService.class)." This person was aware of Spring and Guice, and was told that he was to create his own instead of using a third party library. This is nuts.

    I feel really bad for this guy, because he's screwed. He's working for someone who is either really paranoid about third party stuff, or hates him, or something.

    The answer is really clear to me: he should use Guice or Spring. (Which one is irrelevant.) At the very worst, he should go to his boss and say "look, we can copy the ideas from Guice word for verbatim and have exactly what we want," which should be a clue for the PHB to just say "why don't we use Guice instead."

    It's scary that people don't know enough about open source and how development in Java is done to rely on well-known and trusted libraries. The runtime library is kept small on purpose. It gives us the most flexibility and power to do what's best.

    Educate your bosses on using the power of the java community. Use what's there. Stand on the shoulders of giants. It's the only way not to drown.

    Threaded Messages (11)

  2. ServiceLoader?[ Go to top ]

    If they can't/won't consider Spring or Guice, and they have the good fortune to be targetting java 6 or better, they could use Java's built-in service locator framework.


  3. Don't Do It Yourself[ Go to top ]

    Do you reall presume that you know enough to determine whether this is a bad decision?  How do you know that this requirement isn't really important, possibly for non-technical reasons.  I tend to agree that reinventing the wheel is a bad idea if it produces no advantage over existing wheels.  The other side of that is that if it does produce advantage, it isn't necessarily such a bad idea.  Right off the bat, eliminating or avoiding a depdency has benefits.  Whether the costs of doing it yourself justify that benefit is a tricky question.

    The problem with rigidly dismissing anything that appears to have been done by someone else is that you can never improve on them or gain advantage over competition.  If Bob Lee had thought this way Guice wouldn't even exist.

  4. A better solution is to download the source code for Guice, and do a full find and replace, replacing all references to Google packages with his own domain name. Also remove all references to developers in the JavaDoc to your own name. Then slowly over the next five or six months release parts of the code to the boss, demonstrating all of the intense work you're doing. Bill some overtime and let them know you're working hard. It's as simple as that.

  5. Don't Do It in java[ Go to top ]

    Java - what a horrible language, what a horrible VM (Linus Torvalds).


  6. Don't Do It in Linux[ Go to top ]

    Linus Torvalds - what a horrible hacker, what a horrible OS (me).

  7. why not?[ Go to top ]

    I tried using ‘thrift’ a software open sourced by facebook few years ago. After spending few days on the poor documentation and the tight coupling of dependencies, I felt it’s easier to write my own. If there are justifications for rewriting I don’t see it a problem. Else why would Guice be around when Spring was widely adopted. Google could have enhanced Spring with whatever justifications they provide for it.


  8. DO when it makes sense[ Go to top ]

    Richard you are right, but sometimes third parties offer you:

    when you just need: 

    Or others offer you

    when you need/want something like:

    Or your friends/colleagues say how good and cheap is

    When you're


  9. Not Invented Here Syndrome[ Go to top ]

    Don't roll your own framework unless you have a damn good reason to.

    Use an existing well proven framework that's been used on thosands of projects, by millions of developers (e.g. Spring, Guice) whose code has been looked at by thousands of eyeballs, and therefore more likely to be more bug free than your own home grown framework.

    Your home grown framework will also be more likely to be less documented, and be well understood well only by you.

    If you get hit by a bus, I wouldn't want to be the one to be called in the office at 3am to support the bug in your framework.

  10. Not Invented Here Syndrome[ Go to top ]

    If you get hit by a bus, I wouldn't want to be the one to be called in the office at 3am to support the bug in your framework.

    The question is whether your wish not not support someone else's code trump all other concerns that might drive the decision of whether to introduce a 3rd party dependency.

  11. Wow[ Go to top ]

    Oh still use IRC?

  12. Make it a rational decision[ Go to top ]

    You have to have some kind of process to choose between home-grown vs. 3rd party libraries, especially in the context of the whole lifecycle of a project. Without that, your decision is at best arbitrary, and how can you justify it to your boss?

    Some of the criteria I use when faced with this decision:

    • learning curve: how long before I can use the library efficiently?
    • how mature is it?
    • what's the quality of the documentation?
    • what kind of support can I get, whether community-driven or proprietary?
    • how often does it evolve and what's the impact of upgrading it?
    • how compatible are the licence terms with my project?
    • ....

    Whatever your own criteria, you should be able to derive clear advantages or drawbacks from how they are addressed by an externall framework or library, and base your decision on that.