1. 70
  1.  

  2. 17

    It’s nice to read the Etsy story from the author. Also, his point is something I also agree with, having gone through similar product lifecycles (from creating something new and fun to maintaining and iterating on it). The main takeaway from these slides for me is this:

    Software that’s been around longer tends to need less care and feeding than software that just came out.

    This, a thousand times. Once you worked with a mature piece of technology in a domain, you get to relate and compare to it. A great example at my recent company is Go. We have two camps of engineers: ones who want to use Go and those who vote for Java. The main argument for the Java folks was the maturity of the tooling and environment.

    Some teams chose Go. Some did Java. A few years down the road with services in production, the Go teams started to realise the gap they had in tooling, standard libraries and the lot compared to teams working in Java. Some teams migrated to Java, but most of them are just spending a bunch of time building these tools from scratch or contributing to existing solutions, to add the support.

    There’s nothing good or bad, choosing new and different technologies. But it’s good to take the additional effort and additional learning into consideration when doing so - and in many cases, this might actually be a reason to choose a new technology over an existing one!

    1. 12

      What gaps did the teams run into with Go?

      1. 7

        The biggest limitations we have found were maturity of toolchains and the availability of high-quality libraries in Java that were not there with Go a few years ago. Both have nothing to do with the language and everything to do with the maturity of the ecosystem.

        For example, Java has excellent tooling for IDE integration, refactoring, static analysis, garbage collection analysis. Debugging I’m production has strong tooling support. Go is catching up in these areas.

        Stream packages like RxJava, high-performance networking libraries like Netty, inter-threading libraries like Disruptor were readily available and important to some services that decided to go with Java. Again, a lot of teams/services either did not need these or considered the lack of them no dealbreaker when going with Go, considering some of the other upsides, like the canonical style and the strong community and growth around it.

        Most of my points were for Go 2-3 years ago. The ecosystem is growing fast, libraries and tools becoming more mature. But this approach will be true for the next “new” language or framework a team picks - which may not even exist today!

        1. 6

          We’ve run into situations with inconsistent quality with ecosystem libraries (lots of breaking changes requiring aggressive vendoring / forking), or just not having an equivalent library.

          One example until recently was a MongoDB driver (this is, itself, probably worth scrutiny in the first place), also libraries for working with PDFs. Some tooling for AWS Kinesis is kludgy on their go-sdk or just missing features.

          For the vast majority of what you need to do we haven’t had too much we needed to roll custom compared to java though.

        2. 2

          Completely agree. I include this right in the interview screen and job descriptions. Doing so has helped both our organization and the prospective applicants, because some people want to work on the bleeding edge. They’re not going to be thrilled working in our team, where we try to stick with “boring” tech choices.

        3. 9

          One thing that struck me, is that we as a Fortune 50 company with hundreds of subsidiaries, and a commensurate number of software systems and projects, really have a different problem than seems to be discussed here. Over hundred of systems, the issue for us isn’t largely technology and the development/runtime stack, but rather how to better discover and model functional requirements of a problem domain into working code.

          Is seems to me that much developer discussion today, including the author’s talk, is about non-functional requirements and technologies/techniques to meet them. Is this because most systems worked on have trivial functional requirements, and the focus instead is almost entirely on aspects like reliability, scalability and maintainability?

          1. 4

            I like his point (and right now am on a team where we are trying to simplify a lot), but it can be taken too far. The perfect example of boring technology would be MySQL plus Perl, right — they were what everyone was using in the late 90s and early 2000s. But they really did have fundamental problems (in Perl’s case, it is too easy to write read-only and/or buggy code; in MySQL’s case, the default settings lose data, and the correct settings are less performant than PostgreSQL).

            That’s part of why I like his idea of innovation tokens: it accepts that the current state of things isn’t perfect (otherwise why would one’s company exist?), but it forces one to choose and exercise judgment. We need to innovate, but we need to do it wisely. ‘Gee, isn’t this cool? ’ is neither a wise nor a professional way to pick technology.

            1. 1

              I believe the author should use Clojure as an example of boring technology.

              1. 2

                I believe for you Clojure is boring. For me to introduce it, would not be - it is very shiny. I do believe the author addresses this, it isn’t necessarily about the specific technologies but how and why we choose them.

                1. 2

                  He does address it, but it is a bad example that takes away power from the author’s point of view. I’m pretty sure there are a lot of “Clojure maximalists” out there who would think the same. Long old boring Clojure, short new shiny things.

              2. 1

                Great slides, definitely something I struggle with. I love playing with new tools/toys, but rarely get the full value from them before finding something else shiny and new. Then I get hit with the productivity loss regrets. “I could be finished by now if I didn’t spend so long researching and fantasizing about using datomic/clojure/haskell/lisp/zig/erlang/whatever”

                1. 4

                  There sure are fair points. However, there are also other things to remember:

                  • The ultimate boring technology is COBOL.
                  • For one Erlang startup that failed, there are 20 PHP startups that also died.
                  • Writing PHP code in Erlang is doomed to fail.
                  • If a screwdriver didn’t work for the guy who used it on nails, it says nothing about its feasibility for driving screws.
                  1. 3

                    The ultimate boring technology is COBOL.

                    I’d say COBOL is not the most boring language any more due to a lack of people who know how to program it. Perhaps that is a known unknown, but it also increases all other types of unknowns because you might not have people who know about COBOL’s limitations working on your project.

                    1. 2

                      I feel like it’s missing the point to say that COBOL is the boring language regardless. As the author demonstrates, boring is largely defined by the existing technologies at the company you’re working at. It’s very rare to be in a position where you’re picking a language or db wholly without influence from the existing software ecosystem at your company.

                    2. 1

                      Yeah, erlang is probably worth it for what I am doing, and very stable. For my current main project I selected Go which is pretty boring and does the job, but I always wonder about supervisors and distribution being much easier with erlang.