16 ms·

Choose Boring Technology

• forgotmypw17 6y ago
  I avoid adding anything less than 20 years stable to my "stack". It's proven and stable, it's bound to have a wide install base, and there is 20+ years worth of knowledge on the web for every issue I may happen to run into.
  • qz2 6y ago
    Try that with .net. They fucked it up at least four times in that 20 year period and there’s lots of garbage information around now. Realistically the best approach for stability is to pick mature technology and that means stable, well designed and slow moving. Things like enterprise Linux distributions, Postgres, Go etc.
    • ivan_gammel 6y ago
      Java is mature to the point when legacy is considered a best practice even when it’s not (e.g. JavaBeans style getters and setters). Old and mature may sometimes mean that you will work with the efficiency of developers from 20 years ago. I personally prefer an approach with controlled risks, doing as much experimentation as possible on a solid foundation. Scala won’t fit here as it pretends to be a platform, but this allows to avoid J2EE quagmire with smaller or better designed frameworks and libraries.
      • qz2 6y ago
        Java is a mysterious one really. It’s probably the most complete stack of all but you’re right about the legacy. I find it difficult to evaluate which technologies are risky with it now because some of it is throughly abandoned.
      • eecks 6y ago
        Second comment I have seen mentioning JavaBeans style getters and setters. What is the issue with it?
        • ywei3410 6y ago
          There's nothing specifically wrong with it; just that dogma without understanding why you're doing it is always problematic. If your coding rules state that /every/ object with any properties needs an associated getter/setter/Builder/Factory for any code then it quickly leads to a huge amount of code and indirection to do the most trivial of tasks - made worse by the fact that Java doesn't have first-class macros. In regards to getters and setters specifically; this stackoverflow post is quite good [1]. If those reasons don't apply then it just ends up complicating the solutions for very little benefit. [1] https://stackoverflow.com/questions/1568091/why-use-getters-and-setters-accessors https://stackoverflow.com/questions/1568091/why-use-getters-...
          • ivan_gammel 6y ago
            Actually there is something specific: while individual field accessors may make sense in some use cases (ActiveRecord or bidirectional UI mapping), the naming convention for them chosen in JavaBeans (“get/setXxx”) is too verbose and doesn’t make sense at all. Compare: 1. a.getFoo().getBar() vs a.foo().bar() or a.foo.bar 2. a.setFoo(1); a.setBoo(“moo”); vs a.foo(1).boo(“moo”); or a.onSomeEvent(1, “moo”); JavaBeans are often used in reflective mapping, but nothing prevents from using simpler convention the same way.
            • ywei3410 6y ago
              That's a fair point. I hadn't considered the names at all; I suppose one could argue that a three letter prefix is the least of Java's verbosity woes.
            • forgotmypw17 6y ago
              In my opinion, the three extra characters are worth it for reducing ambiguity. For example, it's clear to me what setFoo() and getFoo() does, but what about foo()? Does that return the value of foo() or does it run a process called foo()? JavaScript has a different but also unambiguous way of doing it, with a.foo used for properties, and a.foo() used for function. foo() is neither here nor there.
    • gnud 6y ago
      I'm in a .net shop, and I've avoided most of the drama by sticking with .net 4.6/4.7 until now, and just ignoring anything to do with "core". I'm sticking my toes in the water with the new .net 5 now, hope I've waited long enough.
      • merb 6y ago
        that wasn't a good move since 3.0 it's really really stable, heck even 2.1 and 3.0 barley changed. 5.0 is basically just a package upgrade (well npgsql+efcore has had some trouble, but that took only a few days) also if you did not use webforms it was basically also just a rename of using statements and impl classes between 4.7 and 2.x
        • gnud 6y ago
          If it's true that there's no real difference in libraries between 4.7 and 2.1, that makes me even more sure I made the right choice. I skipped a load of stress, and didn't even miss any important new knowledge.
          • qz2 6y ago
            There are a lot of changes. Don’t assume that poster is correct. A lot of the core HTTP stack has changed and a whole chunk of third party libraries are abandoned or rewritten entirely for .net core. Anything async is likely to be a complete pain in the ass.
            • merb 6y ago
              Year the http stack was rewritten, But mvc handling was barley different between 4 and Core (besides namespaces)
      • qz2 6y ago
        Enjoy that. I’ve got a huge project which is wedged on 4.8 eternally.
    • forgotmypw17 6y ago
      I should clarify, I meant stuff that's remained stable without many breaking changes for 20 years.
  • deleted 6y ago
    [deleted]
  • speedgoose 6y ago
    That may work on the backend but not at all on the front-end. 20 years ago was the time of windows 2000 and Mac os 9. Not much about mobile applications. You could still use web technologies supported by internet explorer 5 though.
    • forgotmypw17 6y ago
      With a bit of squirming around, I've been able to write for Netscape2+/IE3+ and today's Chrome (and everything in between) at the same time.
      • chrisweekly 6y ago
        Absent a link to support your claim, color me skeptical in the extreme that your "squirming" led to something remotely resembling a reasonably interactive, performant, maintainable web application. Perhaps you mean you've published some static HTML documents resembling a 1990's website?
        • forgotmypw17 6y ago
          The link is my profile. It is a forum website with accounts, tagging, sorting, and moderation. All these features are accessible to Netscape 2+ and IE3+, and also Opera 3+, Opera 12, Lynx, Links, w3m, NetSurf, Dillo, and many others, with and without JS enabled. Accounts require cookies for now. Some enhancements require JS. Mostly built by one dev in (copious) spare time. My motivation is to preserve the knowledge of building compatible Web apps, to allow anyone to access my site, and to embarrass the big websites which complain if your Chrome is a couple versions behind. I believe in aiming for 100%, not 95% accessibility, and here are some scenarios I've tested with: * Older devices like my beloved iPads running iOS 7 and 8, which won't upgrade past that. * Vision-impaired users with screen readers. * Library computers stuch with IE and very old Firefox. * Restricted access connections, browsing (and posting, and voting) via Google Translate. * Slow connections and slow devices forced to browser without JS. * Text-mode browsers Lynx and Links which were my only option at the time. * Device without a keyboard available (I have several on-screen keyboards to choose from) * Device without my keyboard layout of choice. With JS, I have two translit options at this time: phonetic-Cyrillic and Dvorak. NoJS support to come. * Retro browsers from a long time ago with their unique beauty and features, e.g. Mosaic, IE3, Netscape, IE6, Opera 3, etc. Some may consider these to be "edge cases" not worth a bother, at less than 0.1% of the visitors. I guess they might also consider a wheelchair ramp unnecessary, since it only gets used like once a year. I consider all these scenarios to be opportunities.
  • pgt 6y ago
    This is why I write Clojure. Lisp is Lindy. Lisp has been around for 60 years. 60 years from now, Lisp code will find a way to run.
  • throwaway293823 6y ago
    There's a big disconnect between many organizations that use libraries, compilers and tools from OS packages on stable Linux distributions, and the HN/SV crowd that uses docker, or pip/npm/go get/cargo even on production.
    • 7331 6y ago
      What's SV?
      • forgotmypw17 6y ago
        i think silicon valley. hn has a big crowd of retro-lovers and nojs browsers.
        • throwaway293823 6y ago
          Judging from the downvotes when suggesting to selectively disable js, that crowd is a small minority.
          • forgotmypw17 6y ago
            I comment on nojs matters often, and I've found that a lot depends on my tone and writing style. If I'm terse and rude, I definitely get downvotes. If I'm verbose and explain my points, it's less likely, though still possible.
      • Toutouxc 6y ago
        https://en.wikipedia.org/wiki/Silicon_Valley https://en.wikipedia.org/wiki/Silicon_Valley
  • schwartzworld 6y ago
    What a stupid metric. 20 years is an insane amount of time in tech. HTML Canvas is only 16 years old.
    • forgotmypw17 6y ago
      Thank you for your feedback. I'm glad you think it's stupid. I make some exceptions, and Canvas may be one of them in the future. It's not a hard limit, more like a guideline. I want to make stuff that lasts at least as long, and that means I should use tech that's already been around that long, to take advantage of the Lindy Effect.
      • schwartzworld 6y ago
        But can't that backfire? Python 2 just meets your criteria, but you shouldn't use it, vs Python 3 which is only 12 years old.
        • forgotmypw17 6y ago
          In what way is that a backfire? Python 2 was retired after 14 years. It began to show signs of impending retirement after about 9 years, in the form of fork of "new version", parallel to diminishing support of 2.x. I saved myself a bunch of time on a rewrite.
  • Too 6y ago
    What about security vulnerabilities? Unless these are airgapped machines or otherwise not interoping with the rest of the world, you still need regular security patches to keep up with the latest ingenuity of hackers. And please don't say that old tech is immune to this, remember shellshock, rowhammer, goto-fail, spectre and many more.
    • forgotmypw17 6y ago
      As far as browsers go, when visiting my own trusted sites, I don't worry too much about vulnerabilities. Most of the vulnerabilities are also JavaScript-driven, which is optional on my sites. On the server side, of course, I use stuff which is still maintained and sometimes a multi-layer security approach. There is no shortage of both established/mature and still-maintained tech around. Some examples I appreciate: GNU, POSIX, Linux, Perl, SQLite, PHP, Apache, Tcl. For all of these examples there are many accessible resources with oodles of knowledge in many different convenient forms. Newer stuff, where the main resources are Reddit and StackOverflow, and the writing is limited to just a couple of years, is nowhere near as rich or useful. Many newer sites are also heavy and JavaScript-laden, both of which slows down access and skimming speed, if I can access them at all.
• artemonster 6y ago
  I don't like this sentiment, because it assumes you're running just-like-the-other hip startup that ships some sort of bullshit web-app with DB, backend, frontend and all that crap that media nowadays calls "tech" that caters to that mythical "user" that demands features and releases like oxygen. There are, though, many cases of _technology_, like serious number-crunching simulation engines, where using "boring" "standard" technology would mean that you would spend 80% of your efforts battling limitations of your stack and 20% developing towards your goal.
  • simplyinfinity 6y ago
    Yes, but 99% of software written is CRUD apps with custom process & business logic.
    • artemonster 6y ago
      96.7% of statistics are made-up on the spot.. and this is a very broad generalization.
    • banachtarski 6y ago
      Maybe in your universe
      • pc86 6y ago
        Most software is CRUD apps, because that's all that most companies need. Your small piece of the market might be different, and that's great and everything, but it's still just your small corner of a larger, mostly-CRUD universe.
        • banachtarski 6y ago
          I'm not going to throw out a wildly inaccurate number, but based on pure market capitalization, I'm willing to bet the majority of software driving the primary products sold by companies globally is not just CRUD apps.
• jillesvangurp 6y ago
  I'd say pick mostly boring technologies but step out of your comfort zone once in a while. That way you take on some risk but not a lot. Worst case you have to change your plan but you always learn something. Best case your bets pay off and you end up with something that provides you some benefits. And you learn something.
  • greenkey 6y ago
    This is good advice. Another thing to consider is cost-to-benefit ratio. If you don’t know cost, first look at: Product costs: free < one-time cost < recurring cost or recurring “one-time” costs Resource alignment costs: (Re-)hiring + severance + knowledge lost or transferred to competitors Refitting and development costs: converting or re-writing code + (re-)training + architectural changes + design changes Time + impact to other initiatives and maintenance Don’t stop after costing! Then listen to the perceived benefits or need again, being careful to communicate and discuss the perceived costs, so that those selling the idea within the company understand, because if they don’t, their good idea will be poor morale fodder later. This is much quicker and easier than it seems. If you still haven’t convinced the elements within the company to back down on their idea, and you’ve done a good job listening and considering their points, then either those elements are onto something or they’re “on something” (drinking the kool-aid). Make your decision.
• deleted 6y ago
  [deleted]
• silvestrov 6y ago
  I like to think of it as having a budget. Just like you have a budget for the amount of money you can spend, you will have an amount of complexity/uncertainty your team can handle. If you go over budget, the project will fail or slow to a crawl.
  • LeonB 6y ago
    The article that inspired the article above (it links to it) is “ https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology “ and it includes the idea of “innovation tokens”
  • vendiddy 6y ago
    I prefer this model as well. When in doubt or when the newer tech is merely an incremental improvement I will go for boring tech. But sometimes a non boring technology has large enough benefits that make the risk worth it.
• baxtr 6y ago
  It probably depends on many factors. Complexity for example. I’d always chose Jekyll over Gatsby for a simple static page. Sometimes though, trying new things is great too, for example we choose Vue over React 5 years back when vue was very new. I am still happy with that decision.
• WilTimSon 6y ago
  This, just like many opinion pieces I encounter, feels like someone who went "I have a revolutionary idea! What if we... took things in moderation?" and then did a huge write-up on that basic concept. Yeah, don't rush to use new tech just because it sounds glitzy and fresh but don't get bogged down in the same old tools either.
• knowhy 6y ago
  I find it a bit contradictory to argue for boring technology and operate it with Kubernetes at the same time.
  • burnthrow 6y ago
    The post describes a handful of technical decisions with no common thread, really.
  • amzans 6y ago
    Kubernetes is used by thousands of companies, big and small, has been around for more than 6 years, and is well supported by various cloud providers. There's lots of documentation and forums online with plenty help. It'd argue that there's more documentation available than for any home-grown deployment system. That's why I consider it battle-tested for my purposes. Also, the post explains that boring does not necessarily mean "old". It's about using what you know best.
    • eeZah7Ux 6y ago
      > There's lots of documentation Sure. > battle-tested Not at all.
  • jpgvm 6y ago
    k8s is boring at this point. You can purchase it as a managed service from the biggest vendors on the planet and reliably find people with 2-3 years experience working with it.
    • knowhy 6y ago
      I have worked with EKS for the most when it comes to k8s and I don't find it as smooth as AWS's other offerings. Check the upgrade guide https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html https://docs.aws.amazon.com/eks/latest/userguide/update-clus... There is still quite a lot of engineering needed even when using a "managed" service.
      • 6y ago
• jpgvm 6y ago
  JVM + PostgreSQL IMO. It's fast enough for almost everything, you get choice of Java/Kotlin/Scala/Clojure depending on taste. PostgreSQL can represent almost any storage paradigm you want from traditional relational schemas, to graph like structures with recursive CTEs and even NoSQL JSON document style with jsonb. Everything is super well supported with consistent release cycles, minimal regressions and runs on almost any platform. Tooling support is superb ofcourse - IntelliJ makes working with the platform a breeze. You get all of the JVM debugging and profiling capabilities and PostgreSQL has EXPLAIN ANALYZE making getting to the bottom of performance problems simple. If you want to take on fancier paradigms like ES/CQRS/CDC you have best in class libraries and tools all built on the JVM. Debezium + Kafka being one example. Need faster OLAP queries than a PostgreSQL replica can provide, Druid is JVM based and can be integrated with Debezium + Kafka + Avro for streaming ETL. These sorts of tools are ideal because they are already best in class but can also be easily extended with any JVM language. Want to do big data processing? If you are already on JVM it's easy to plug in Hadoop/Spark or one of the Apache Beam runners like Google Dataflow. List goes on, there are literally hundreds of fields where JVM beats all other platforms out as it's the most general purpose platform available. It has real threads so it's not limited where single threaded languages are. It has multiple best in class GCs (latency or throughput tuned as you please). Best JIT by far with reasonable SIMD optimisations (annotations coming soon for guaranteed SIMD on supported platforms). JVM might be old but it's 2020s most promising platform. Rust and .NET are up for contention too but with Project Loom and Valhalla on the horizon I don't see anything beating JVM in the next few years.
  • dmos62 6y ago
    > with Project Loom and Valhalla on the horizon I don't see anything beating JVM in the next few years Don't forget the low-latency GCs, like ZGC: https://wiki.openjdk.java.net/display/zgc/Main https://wiki.openjdk.java.net/display/zgc/Main
    • jpgvm 6y ago
      Yeah for sure, I sort of mentioned this with latency vs throughput tuned GCs being available but I guess it's worth pointing out just how insanely good ZGC and Shenandoah are.
• fendy3002 6y ago
  Do everyone read the article? In the article it specifically mentions: - boring means proven, not necessarily older tech - the ratio is 80 proven and 20 percent new tech IMO it's a reasonable approach for production / commercial apps (maybe not for newer, cutting edge apps) to maximize productivity and keep earning experiences. Then the more basic question is: when does one tech is considered "boring" already? For most apps, even the newer tech should already cover most, if not all the use cases. Edit: formatting
• nickjj 6y ago
  It's true. I've been burned a few times trying to pick something new to base a non-trivial app on. Almost every time I do this I end up running into bugs that haven't been reported or documented anywhere. Building an app and starting a business is hard enough. Having to pioneer a new tech (when you're not the inventor of the new tech) is a massive burden if it's not a game changer for doing something critical in your app. At this point I've spoken with 74 different devs who built 74 different apps (big and small) on a tech stack oriented podcast[0] and by far the most common trend they bring up is keeping things simple and choosing boring tech. This round up post[1] goes into more detail on innovation tokens (aka. a system for choosing new tech in a controlled way) and other trend extractions from 50+ episodes. [0]: https://runninginproduction.com/podcast/ https://runninginproduction.com/podcast/ [1]: https://nickjanetakis.com/blog/talking-with-52-devs-about-building-deploying-web-apps-and-tech-stacks https://nickjanetakis.com/blog/talking-with-52-devs-about-bu...
• ChrisMarshallNY 6y ago
  I write in Swift. Swift is six years old. The difference is that Apple, the most valuable corporation on Earth, has backed it 100%. They do occasionally kill initiatives (Can you say “OpenDoc”? I knew you could!), but not at the 50% rate that Google does, so I knew it wasn’t a big risk. Also, I really enjoy the language. It’s a long-term investment, and I don’t expect it to really start paying any dividends for at least another couple of years. I would be fine, sticking with ObjC, which I know will still be around for at least another decade. But I’m at the point in life, where I want to work with tech that I enjoy.
  • keyle 6y ago
    My problem with swift is that it's moving faster than most people are comfortable with. Documentation is bare on the newer versions, every example on stack overflow is probably out of date, and it's really frustrating when trying to get things done. Oh and did I mention xcode?
    • ChrisMarshallNY 6y ago
      Xcode is a bug farm, but that was the case, long before Swift. Its bugs aren't "showstoppers," though. Really just annoyances. The biggest issue that I have with it, is that it is huge, and takes forever to download and install. Swift documentation is pretty sparse, but a fairly robust "tribal knowledge" base is developing. StackOverflow is not bad. Most answers I see have at least "Swift 3" variants, which is really the line of demarcation. It usually takes me thirty seconds to tweak for language changes. Xcode is fairly helpful, there. A lot of the "moving targets" in Swift are the system framework SDKs and APIs. The language is morphing, but mostly in less-frequented corners.
  • Veen 6y ago
    Are you using Swift on the server, or just for iOS/Mac apps? I like Swift but it seems the consensus is that's nowhere near ready for server-side stuff. I'm leaning towards Elixir/Phoenix/LiveView for a project I have in mind, largely because I'm a (very) amateur developer and Elixir's way of doing things clicks with the way I think more than Node, which is the only other language I'm basically competent with. Plus, I guess with BEAM, the Erlang underpinnings, and Ecto's excellent PostGreSQL support, Elixir counts as "boring", well-tested technology.
• jsnell 6y ago
  It seems like this article is basically just restating point by point a classic article / presentation of the same title, https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology This article does link to the original, so it's not uncredited plagiarism. But it still feels a bit odd. The original has been discussed really extensively on HN in the past, and even quite recently: https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=23444594 https://news.ycombinator.com/item?id=23444594
  • amzans 6y ago
    Hey thanks for the feedback! I'm the author of the blog post. The topic has been influential for me, and I just wanted to share my perspective on it, specially in the context of a recent project. I don't think any other article talks about Choosing Boring Tech in the context of Kubernetes, and building a one-man SaaS. Could you please clarify what you found odd? I'm just curious.
    • jsnell 6y ago
      I mean, it's basically what I wrote above. You used the exact same title as the McKinley's article, the same Maslow's pyramid visualization as their presentation, and went through their basic points in the same order. This meant there was a major feeling of deja vu, it didn't feel like a particularly original take on the subject. Maybe the feeling would not have been there if it had been more obvious. I.e. titled something like "My take on 'Choose Boring Technology'", the link moved to the opening paragraph, and explicitly stating that you were reframing that original article in terms of your own experience. (But to to repeat, I'm not claiming that anything untoward happened here).
      • amzans 6y ago
        Thanks, just updated the article to clarify the context a bit better.
    • 6y ago
• amzans 6y ago
  I tend to prefer tools that have: a) withstood the test of time, or b) I feel comfortable debugging it if my business depended on it. My argument for battle-tested tools is, if they are still being used by a significant community even if no longer "trendy", they probably solve a problem well, there's lots of help online, and the ways in which it can fail are well known. That said, I do try some lesser known tools if they help me ship the product. I just look at them as a risk factor until I understand them better.
  • dmos62 6y ago
    > prefer tools that [...] I feel comfortable debugging it That's really sound advice. > prefer tools that [...] withstood the test of time That I disagree with, sort of. In my eyes, history of tech, and hence tech popularity distribution, is closer to random than optimal. That's probably because choosing a stack is a complex process, subject to many decisions, not all pertaining to a given technology's technical efficiency. That said, if a piece of technology is popular, sometimes its large ecosystem will help bootstrap your project faster. But not all large ecosystems, or communities, are created equal. Some ecosystems, in some cases, even though smaller in size, outperform even the largest ones.
• scanr 6y ago
  I wonder how one would construct a reliable 'boringness' index. I like the idea of people in a room arguing about why their tech choices are the most boring.
• pydry 6y ago
  >For example the other day I had an issue with my Django app, and a quick search led me to tens of answers to this problem in various forums and websites. It took me at most 10 minutes to get back on track and that was the end of this issue. > >I experienced the exact opposite a few years ago with a popular, but not so battle-tested Scala library my team had been using for a while. This issue can be sidestepped to a large extent on non popular technologies by picking technologies which are tightly scoped, well designed and well supported by their maintainers. They'll have fewer issues and the issues that they do have will be easier to diagnose and the maintainers will probably be more help. Being very tightly scoped and well designed means that A) they won't be flooded with issues and B) there's a narrower range of things that can cause issues making it easier for them to diagnose and implement fixes/workarounds. Django is very broad in its outlook. It tries to do a lot. It's also got some embedded design mistakes which make certain problems more common. The size of the community and the wealth of content online makes up for this. Any new web framework that makes half as many mistakes will not get off the ground because it won't have this. Django is also not just a technology. It's as much a community and and set of agreed upon standards for building web apps. It's as much about being able to purchase django suit or use django-rest-framework as it is fixing issues with django itself. The people rather than the core library itself are what hangs it all together (& the people in this community are really lovely).
  • kawera 6y ago
    Indeed and the same can be said about Rails, give or take.
• nikon 6y ago
  I picked up Rails this year after spending a long time dismissing it as a unscalable out of date framework. It’s the fastest thing out there for shipping features. I’m building a SaaS tool, so that’s all that matters right now. I added PDF export yesterday in about 11 lines of code using Prawn. It’s great building stuff in Go, but it’s no good sitting there in a year with 0 customers and a system that can handle 10k rps. Or stuck still building that idea and switching SPA framework or RPC library, as I often did to procrastinate launching. By not using the shiny new thing I can focus on the product.
  • cknoxrun 6y ago
    As a long time Rails developer, pushing products and prototypes out the door quicker than peers, it's heart-warming to see messages like yours more often on Hacker News lately.
  • ulisesrmzroche 6y ago
    I remember when using Rails was the hip shiny new thing and HN said: “how about we pick boring tech instead?”
• 0x008 6y ago
  I think the main point of the article is (and I would also emphasize this) to chose proven and widely used libraries - not languages. You want others to have experienced the pitfalls you might run into so you don’t have to wait or contribute to upstream OSS if you encounter an esoteric bug. Basically, software is business and business is about maximizing profit (efficiency) and reducing risk (bug fixing time). There is a reason why large scale enterprises tend to be behind the curve wrt. tending tech stacks.
• bamboozled 6y ago
  I feel the title is missing, “and use it in the way it was designed.” Choosing boring technology isn’t enough, one must use said technology in mostly boring ways to achieve the desired results. One hacker in our organisation (employed as engineer) used Ansible and built the most abhorrent, complicated twisted and broken Rube Goldberg machine I’ve ever seen, it’s cost us about two weeks to get it just semi-reliable. I’ve found most of the useful solutions and best products sit on the fringes and have boring foundations.
• sp0k 6y ago
  That's why our standard front-end stack is Angular + TypeScript. Microsoft is doing wonders with TypeScript. Thanks to its type system we have much higher level of confidence and amazing tooling, so we can focus on writing tests and solving business problems. Similar with Angular. With the AngularJS to Angular transition few years ago so we were very skeptical and thought that Angular is a ticking bomb. It turned out the opposite! Their team has learned the lesson and now they provide automatic update with their CLI. The framework hasn't changed for the past 4 years and Google just releases incremental updates with improvements in DX and speed. They can definitely work on better build times and forms, but that's the first time we were able focus on solving customer problems without stressing out what's the new trend of creating components.
  • nicoburns 6y ago
    Agree on TypeScript, but Angular (at least when I last used it back in the v2-4 days) was very quirky. It felt like you had to know a lot about it's internals and the change detection mechanisms to make things work performantly, and if you needed to opt out of its model and dip into lower-level DOM manipulation code then that was quite a headache. I've found React to be a much more boring technology where everything just works.
    • sp0k 6y ago
      There seems to be different aspects of boringness. Angular has been boring for us in not having to assemble the frontend stack from scratch, keeping up to date, and hiring people who can immediately get up to speed. The least boring part of Angular for us was rxjs and forms. It's awesome having rxjs experts, but for folks getting started it can get messy. We decided to limit it's usage, and things have been going pretty well so far. In terms of performance we haven't hit any issues, but I suppose it depends on the app you're building. We've had successful React projects as well. There the boringness was coming from the intuitive approach for building components. We found it less boring when we had to keep up to date, be consistent (used technologies), and have smooth integrations. Hooks felt very much similar to rxjs where there's so much semantics behind a short name to the extent you need to dig behind the implementation to understand what given hook does.
• pm 6y ago
  As an addendum, choose technology you enjoy. As a consequence, it should be something you already know, but you'll be so more productive because it won't feel like a chore.
• tannhaeuser 6y ago
  But boring doesn't bring young developers to your team. Like it or not, there's a fight for relevancy going on, fought by developers wanting to carve out either a niche for creativity, or, less favourably, longing for job security, resume padding, or self-promotion. And there sure is an effect of platforms building up a legacy of fossilized enterprise tooling turning younger devs away, such as Java; at a customer of mine, a team even chose Kotlin in a secret move to be presented after the fact. This was for a basic FinTech backend, so since it wasn't even Android development, I can only assume they wanted to pad their resumes. Same thing at a bank where they chose nodejs when it, as much as I like it for lightweight web backends, really lacks basics such as decimal arithmetic and its always-async nature only spells trouble for integration work, debugging, etc. If it were only for bare requirements of business CRUD applications, we had it nailed around 1990 with client/server SQL apps already. Ever since, we seem to long for wrapping stuff up for modularization: first OOP, then package management, then "modules" (in Java land since v9/11, and OSGI before that), SOA/microservices, containers/k8s, with their accompanying zoo of tools that really don't make things any better in the slightest. About the only real progress I can see here is that modularization made unit testing mainstream.
  • lmeyerov 6y ago
    I've learned to recruit on mission, not tech. Though ironically, half our charm is the tech we bring to our mission :)
    • bob1029 6y ago
      I have inspired several young developers simply by showing them just how quickly you can deliver compelling functionality to customers and the positive reaction that generates. For us, speed of delivery is an explicit feature. Thinking in terms of "fun" tech, these are more-or-less antithetical to the idea of quickly shipping something that is predictable. The coolest piece of tech we use is probably a toss-up between .NET Core, Blazor and SQLite.
• fiftyacorn 6y ago
  The best chapter in the Google sre book I about this same point. Wish more people would follow it
• solatic 6y ago
  Be careful. What choose boring technology really means is choose boring technology for anything not related to your competitive advantage. It is the engineering equivalent of MBA advice to differentiate between core and context, and choose boring technology for anything that fits in "context". Maybe your business's competitive advantage isn't related to your technology stack, in which case, all of your technology had better be boring. But sometimes, you really do need to run that brand-new shiny 5-GitHub-stars project in production. If you do, you just better make sure that you're one of the core maintainers, and that the time you sink into it more or less directly translates to business success.
  • theshrike79 6y ago
    This is where experience comes in. You need someone in charge who can see when you REALLY need to break out the latest javascript library that was released last week vs "I'm bored and want to use something shiny at work".
    • Guest42 6y ago
      I had a manager tell me that Blockchain was a better choice for our enterprise transactional data management. Since then, I've refrained from all technical discussion.
      • theshrike79 6y ago
        Yep, worked on a product that had an "immutable blockchain audit log". ...which was a single node blockchain implementation. But hey, the manager who got the blockchain crap implemented got a nice job at a huge company out of it, so it wasn't a complete failure =)
        • paulryanrogers 6y ago
          > manager who got the blockchain crap implemented got a nice job at a huge company out of it, so it wasn't a complete failure Not for the manager's personal career, no. But probably a failure for both the original company needing to maintain unnecessary complexity and the new company hiring a manager who prefer resume/fad driven development.
• lmeyerov 6y ago
  I've gone more extreme on the 80/20 ratio, instead thinking as innovation points. Fine to have a few risky things, but that should largely be driven by the business, not dev. Having 20% risky deps that you might need to track changelogs on and fix adds up as you keep adding code. We do some wild GPU and data stuff, and time spent on weird js/python/infra/etc lib issues from old risky deps is time not helping our core and our users. Nowadays, we try to remove deps, not add. Putting 20% on innovation in the codebase makes more sense when thought of as % time improving, not the mix of risky deps. Ex: We invested in switching to more modern CI as useful innovation in the codebase (serverless GPU CI w gh integration, PR artifacts/snapshots/reproducibility, config as code, etc)... but done intentionally with boring code (gha/docker/packer). This brought in new ideas that took some iterations, but the boring code means it's only had one real incident, and all that has been justified in the business by the productivity ROI.
• spacekitcat 6y ago
  In principle, I see the point the author is making, but I can just picture my boss from a few jobs ago using this to justify IBM WebSphere and SVN.
  • deleted 6y ago
    [deleted]
• jb3689 6y ago
  "Choose boring technology" implies many different things. I don't like this phrasing because it doesn't identify what part of "boring" is important: * Is boring tech good because older tech with lots of commits is more likely to have identified bugs? * Is boring tech good because it is easier to find devs with skills in those areas? * Is boring tech good because it has lots of fleshed out examples to follow/SO support/packages? * Is boring tech good because it is simpler and has less moving parts? Simply saying "Postgres" or "JVM" doesn't imply boring either. Both of these have lots of advanced features and complexity. Your interactions need to be boring (simple, avoiding advanced features). Moreover it's very powerful to make your application boring. What if your whole app could only read/write data in one place? What if your whole app could be single threaded rather than multi-threaded (and still deliver results)? There are good reasons not to do these things, but those cases are rarer than the times we jump to these solutions which can create difficult problems that make our lives harder later
  • chridou 6y ago
    I agree with you and would even go a bit further. Actually the word "boring" is completely misused in my opinion. It is all about choosing the right solution. This has nothing to do with things being boring or fancy. The word boring is clearly defined by a dictionaries and is subject to personal emotions. One could say the JVM is totally amazing while the other says it is dull and boring. This can not be the basis for an educated decision. The points you mentioned are also part of the questions one has to ask for finding a suitable approach. I think that all those who say "use boring ..." effectively want to say something else but either do not dare to do so or are otherwise unable to express their intentions. Nevertheless redefining the word "boring" is not a solution.
  • collyw 6y ago
    The essay makes it fairly clear to me. There is a constant churn of fads in the tech world. Usually they are beneficial for some specific use cases, but get hyped up beyond all belief until everyone wants to use the new tech without questioning whether they should or not. If there aren't ton's of articles about how great a new tech is then it's probably "boring". Think of it more in terms of fashion than interesting.
• harimau777 6y ago
  How does this relate to continuing education/professional development? It seems to me that engineers choose non-boring technology because that's the only thing that most companies provide for professional development.
• rubyist5eva 6y ago
  This is why I always start with Django or Ruby on Rails. It's "boring", battle-tested, has great support and gets you _very very_ far before you need to choose $HOTTECH. Choosing $HOTTECH too early will destroy you. Building an entire business around $HOTTECH when the majority of people barely have a business model or a defined market are just asking for trouble. It's also substantially more difficult and expensive to recruit for $HOTTECH but if you form a solid team on boring tech, and you build something sustainable that actually makes money, you can invest the time into building something with $HOTTECH and create subject matter experts out of your "boring" team. This is why our company primarily recruits from coop programs - you can mold them into experts without most of the baggage from grey beards.
• jorangreef 6y ago
  I don't think it's a question of "boring" or "proven" vs "latest" or "newer". It's not even an 80/20 split between "use proven technology" and "explore new tools". What it all comes down to at the end of the day is "quality". You need to have an eye for quality, you need to be able to recognize good design decisions when you see them, appreciate their worth and weigh their potential. You need to be able to make up your mind for yourself. If you can spot quality in a language, framework (assuming you even need one) or database, then "boring" or "proven" become meaningless phrases. Quality transcends age and hype. When you can spot quality far off, you can paddle out to the swell, be there as it breaks, and enjoy a long quality ride that's not cut short because of irrelevance. You won't need to see thousands of surfers on a wave to know it's a quality break. With technology, the earlier you can spot quality, the sooner you can start riding the wave and benefitting from everything that comes with that (long term experience with that technology, deep understanding, the opportunity to shape or introduce key design decisions at a critical stage, learning from new ideas that can compound earlier into your own output, new connections and marketing opportunities). That's how it always works. There's no point catching a wave because everyone else is riding it. By then, you probably need to be paddling out for the next big swell. To be clear, this is more than "skating to where you think the puck will be". This is looking for quality and having an eye for it, and being sure of it when you find it.
  • mobjack 6y ago
    Quality is overrated when it comes to tech. A quality product can be written with many different tech stacks. You just need to be able to recognize what is good enough to get the job done. I can often deliver faster choosing a good enough stack that my team knows compared to finding the best tool for the job.
    • jorangreef 6y ago
      I would say quality is undervalued when it comes to technology. Technology suffers from a plague of bloat, and it's getting worse as high level languages pile on the dependencies and abstractions, all the while justifying the waste with "quality is overrated". I find it hard to believe that you can ship a high quality product without caring about the quality of the components going into it, or that this won't cost you down the line. It only takes a few "good enoughs" in terms of probability theory to end up with a multitude of poor product tail results. It's also not enough to get the job done, you need to maintain what you ship. You don't need to choose the absolute best tool, but choosing quality tools pays dividends over time.
• veesahni 6y ago
  When we started building Enchant [0], we used some tech that we understood well and some tech that was new and shiny. Over the years, most of the new and shiny choices eventually caused more pain than we had ever anticipated. We ended up either ripping them out or working around the problems they introduced. But I think "choose boring technology" is not a great guiding light. I've written previously about how to pick the "Right" technology [1], but I'll summarize below: * It's not about using the right tool for the job. Sometimes, the right tool for the job isn't the right tool for you right now. It may be too expensive, you may not have the team necessary to maintain it, it may not integrate well with your existing stack * It's not about using boring tech either. Boring tech can be antiquated already (or on a rapid path of getting there) So how do you chose the right tech? * Sometimes the "right" tech is already there - your existing tools may already be able to do what you need to do "good enough" for the next order of magnitude of scale. This buys you time before you need to take on additional complexity. * The right tech is proven and widely deployed - and looks like it's still has a good trajectory going for it .. i.e. people still care about it! * The right tech is robust - it's already battle tested and handles all the edge cases and big business needs. Security releases, zero-downtime upgrades, high availability and backups, known paths to scale, strong community, etc.. But this isn't a one time thing. When you start seeing signs that the tech is losing favor to newer better things, you also need to plan a migration or you end up stuck in the past (with poorly supported tech that's hard to hire for). Today, having learned our lessons (the hard way), we evolve our tech stack much more methodically. 0: https://www.enchant.com https://www.enchant.com - shared inboxes, knowledge bases, live chat 1: https://www.vinaysahni.com/how-to-choose-the-right-technology https://www.vinaysahni.com/how-to-choose-the-right-technolog...
• k__ 6y ago
  The article should use "old" instead of "boring". New tech can be borig too. I think, the main reason people choose old tech is because they know it and don't have the time or the motivation to learn something new, even if the new tech is much better for their business. And who can blame them? If you invested years to become an expert in a technology, it's hard to admit that something better comes along.
  • collyw 6y ago
    >it's hard to admit that something better comes along. 90% of the time it isn't better it just the latest fad. Remember NoSQL was the cool thing a few years back. Now my company is stuck on a shitty mongodb backend for what should be a relational database. We have kubernetes which causes a problems from time to time. We don't actually need to scale for the foreseeable future.
    • deleted 6y ago
      [deleted]
  • Slump 6y ago
    The other point that could go along with this is that often, based on constraints like cost and time, most people can develop a more stable solution using tools they know vs tools that are new to them. It takes time and often working through a lot of mistakes to come to grips with a new technology. Sometimes it's better to use what you/team understands assuming it's still the right fit for the problem. That goes beyond tech industry as well.
• SarikayaKomzin 6y ago
  This is basically the Lindy effect in action.
• maerF0x0 6y ago
  One aspect I see rarely discussed is matching technology to the skill of the team. IMO people should not choose technologies they're unwilling to become experts with, or lack the workforce capable of. It's a hard fact of life that some are just more capable than others (either through intrinsic factors like "Intelligence", or extrinsic like family circumstances, quality of education received et al.). Obviously the extrinsic ones are in our locus of control, so an engineering team that presently is incapable, can grow to fill that need. I don't think most companies w/ a high requirement for quality (say something that affects others' health for example) should use something like AWS unless they have a workforce dedicated to understanding distributed systems (academically) and become an expert in each AWS technology they choose. I have observed so many engineers treating these tools w/ their wishful assumptions of how they ought to work versus how they actually work... There's probably a similar conversation to be had about databases' guarantees, consensus algorithms, amongst others...
  • ianandrich 6y ago
    I've had similar constraints based off my experience. Tech stacks being driven more by developers experience than whats necessarily the best possible fit. I can second the AWS mysticism as well.
• robomartin 6y ago
  > To be clear, fuck this guy. Arghhh...why do people feel compelled to virtue signal in such stupid and unnecessary ways? This is an article about technology. Want to discuss politics? Fine. Write an article about politics. Don't shoot yourself in the foot with politics. It's a bad idea. I know people who have absolutely ruined their careers mixing politics with work. One guy had to move to another state because nobody would hire him. I feel younger folks are particularly naïve about this stuff. I don't care who you think you support today, left, right, middle, Martians. I guarantee you that life will eventually make you regret some of your choices and even change your mind. Do not take a red-hot poker in the form of words and brand yourself on the internet with something you might just live to regret and will not be able to erase. You never know who's reading your stuff. And don't say, "I don't care". I know people who have lived to regret thinking that way. If you want to write about tech, write about tech and leave all else out of it. I have lived in countries where changes in the prevailing regime came with serious consequences for those firmly and publicly aligned with the prior regime. People in places like the US (particularly younger folks who just don't know the history and nature of the world) don't understand the idea that something that might seem to like favorable virtue signaling in one epoch can turn into a death sentence when the tides change. Don't get on lists or clans unless you fully understand the potential consequences. You want to be a software developer? Fine. Don't be a Democrat or Republican software developer. Believe me, it will cost you and you will likely never know it is happening to you. All you have to do is reflect on what you are thinking this very moment as you read this --particularly if you down-voted the comment. Some of you are thinking something like "this guy is an idiot, I would never want to work with him". Well, there you go: QED. Regarding Donald Rumsfeld. "Fuck this guy", among other things, says, "this person is ignorant". Not an insult, just a statement of fact. I seriously doubt they are able to recite the guy's biography. They likely "know" through a myopic third party unidimensional quasi-opinion of unknow origins. In other words, they know nothing. No, this isn't to say I love Rumsfeld. I like very few people in politics (let's call it zero right now). For example, among other things, did you know Rumsfeld was responsible for moving the world to high definition television? In fact, it would not be a stretch to call him "The father of HD television". Seriously. I was floored when I learned this myself about twenty years ago. He did this outside of government, when he was in private industry. There's a wonderful little book titled "Defining Vision" that is a super interesting read about how the US, and the world, moved to HD TV. It's a great book about the tech, business and political sausage making that got HDTV going. Imagine my surprise when I was reading a book about technology and Rumsfeld surfaces as the key player that made it all happen. I have learned we should strive not to manufacture ignorant caricatures of people and paint them in a negative single wavelength light after reducing them from a complex three-dimensional being to a single point in space. This is no different from saying people crossing the border are criminals, that all Democrats are communists and all Republicans are idiots. These are incredibly ignorant views of reality we should all avoid. Do not brand yourself with such views, it's a bad idea.
• bestouff 6y ago
  Well, I have a problem that if I'm not motivated I tend to procrastinate, a lot. Exciting tech enables some kind of "berzerk mode" in me where I work frantically, i.e. like a normal coder. So I tend to choose exciting tech when I can (and I must say that discovering Rust a few years ago gave me a lot of motivation to enjoy programming again).