62
Comments
  • 7
    Remember Larry Wall’s three programming virtues: Laziness, Impatience, and Hubris.

    http://threevirtues.com

    Though Larry didn’t say so, not reinventing the wheel falls under laziness.
  • 9
    Hey! It's the NPM approach to programming!
  • 1
    @xkill @gitlog words of wisdom
  • 0
    😂😂
    @sifun Thanks 4 the tag
  • 1
  • 1
    While I agree with the basic idea very much, things are often not black OR white.

    For example, if you want to do one or two things a framework somebody else built can do, is it always better not to reinvent the wheel and use that framework instead?

    What if the framework is complicated to use and configure, and you only really have to use a few particular features?
  • 4
    It all depends on the scope of the project and the time/budget you have.

    For your startup, you shouldn't write your own MVC framework. For your billion dollar company, you should create your own programming language.

    And you should spend time, continuously, on reinventing the wheel, because all existing wheels are square.

    You just have to understand the time investment balance between tweaking the wheel, and moving the vehicle.
  • 2
    yes... and no. i don't get a monstertruck to go shopping. and i don't need a grown ass library for one functionality. some people just overdo it with the laziness and end up in dependency hell.
  • 3
    @git-gud I think the whole issue is:

    1. What is the deadline for the initial requirement?

    2. How permanent is the solution?

    3. What are the treshold values for improving the solution?

    4. How many hours will it take to replace the wheels, compared to creating custom-built ones directly?

    A monstertruck will probably do fine when your wife is in labor, and the hospital is 20km away... but you'll probably want to think about getting a different car afterwards.

    There's always a tradeoff between initial prototyping speed on one side, and flexibility/performance on the other -- and all porting operations cost time as well.

    Sadly, both developers and managers/clients are bad at estimating these values and communicating about them.
Add Comment