1. 10
  1.  

  2. 8

    I did not really feel like this post added anything to the discussion around new vs old tech.

    1. 9

      I agree, while the overall sentiment is probably something most people will agree with, there is no attempt to create a delineation between when to chase something new and when to not. Rewriting your entire product every time a new JS framework comes out is one extreme of it, the other extreme is to try to write everything you do in C, C is very well-understood and very standard, so that means it’s better than everything else?

      The interesting thing to talk about is where to draw the line, but of course that’s more nuanced than you can fit in a single blog post and additionally requires knowledge of the problem domain.

      1. 2

        Agreed - real issue, needs nuanced exploration rather than broad statements. It’s impossible to take the article seriously when it’s proposing a simplistic categorical rule about something so important and subtle.

        A meaningful exploration would be about how to decide which parts of your own project should be new vs. old, with case studies on both sides of the line.

    2. 3

      (note that I’m talking here from having done C, Javascript, Ruby, some Elixir, and various other things)

      Half of the new shiny out there is going to be gone or dead in less than a year, half of it will be around as the accepted technologies for the next five or ten, and half of it will give you fair warning before it autodeprecates itself. The problem is knowing which of these three halves your given tech falls into–and yes, there are three halves, because there’s continually a lot of new shiny.

      The problem is that, sometimes, things that seem super and awesome and Built To Last ™ are so fundamentally flawed that, when you can finally pivot into using them, they get ingrained in your tech stack and become rather hard to remove. I’m currently pissed at my own choice of Angular for my team due to this.

      I think that if we all just accept that all tech is passing, and that the things worth worrying about are operating environments and having tools which are easy to replace/compose, then you can avoid a lot of the danger of chasing the new shiny.

      1. 1

        I think this is particularly insightful. The ability to change and be malleable is far more important than choosing the right thing every time.

      2. 2

        Taking 5x as long to roll out a new feature? Business problem. Can’t hire talented developers because you refuse to move on from “proven tech” like JDK 5 and Struts? Business problem. Bugs creeping in because your dependencies are no longer being maintained? Business problem.

        1. 1

          Taking 5x as long to roll out a new feature and being unable to hire talented developers are only valid arguments if you accept your entire basis is that “proven tech” == “ancient unmaintained garbage”. Therefor I claim your entire argument is baseless hyperbole since anyone can find 5-10 year old major projects on GitHub that are very actively maintained and just as popular.

          Here’s just a few:

          Maybe you misunderstood the definitions presented in my post. Maybe you have a chip on your shoulder about stable proven tech. I’m not sure. But you’ve missed the mark completely.

          1. 1

            Please don’t use personal attacks here - “baseless hyperbole” is satisfying to accuse people of, but it’s really not the intended tone of the site. I’ve found that on purely technical and business topics, when there’s a strong disagreement there are rational reasons, often stemming from perspectives and goals being different.

            Your post does not appear to have made your viewpoint clear to people; this is why it is meeting with disagreement. A productive response would be to figure out why people disagree.

            1. [Comment removed by author]

              1. 1

                Consider it stopped.