[HN Gopher] Boring Technology Checklist
___________________________________________________________________
Boring Technology Checklist
Author : macdonst
Score : 151 points
Date : 2022-01-31 15:36 UTC (7 hours ago)
(HTM) web link (blog.begin.com)
(TXT) w3m dump (blog.begin.com)
| Ishmaeli wrote:
| I feel like I've spent the last 10 years seeing "boring" in
| headlines and thinking mundane, when actually it was referring to
| tunneling. Now I'm finally conditioned to think tunneling first,
| and this.
|
| It's like BLM, whether I think Black Lives Matter or Bureau of
| Land Management, the reference is bound to be about the other
| one, sure as the the USB is always backwards.
| lostcolony wrote:
| This is fine insofar as it provides a checklist to evaluate if
| technology is boring, but it rests entirely on "Choose Boring
| Technologies", which I've never found particularly compelling.
|
| It's less "Choose Boring Technologies" and more "Don't introduce
| something new just because it's new". Have a compelling reason.
| And both this article, and the original Choose Boring
| Technologies, kinda miss that.
|
| I'd be much more interested in guidelines of when to choose
| something new; a prior job prior to my joining chose Erlang for a
| mid-sized project, despite no one on the team knowing it, and it
| was a success. So we chose it (after I joined) for a large
| project, and it was, to quote the executive of a business unit it
| was for "the biggest success to come out of (our department)".
|
| Both of these projects -could- have been done in one of the
| existing house languages...they would not have been done as
| quickly, resulted in nearly as good an outcome (predominantly
| amongst resiliency, which is why we chose Erlang), nor have given
| the team as much enjoyment (itself being part of the reason for
| the results, as a knock on effect).
| allochthon wrote:
| The discussion around "boring" technology is an important one.
| Where to draw the line will be pretty context-dependent. An
| aerospace firm will put the line here, and a tech startup
| focusing on a low-risk use case will draw the line somewhere
| else. And the developers and other stakeholders will be relevant
| as well. In this context, the checklist at the bottom is
| interesting food for thought. But I would be wary of relying on
| it for choices around what technology to adopt, because such
| decisions will always need to be considered in context. In that
| sense, the checklist feels well-meaning and even insightful, but
| a little too concrete.
| julosflb wrote:
| In aerospace engineering you would usually select technologies
| based on a concept of technology readiness level, which
| provides a framework for evaluating new technology and make
| sure you are in control of their maturity.
|
| https://en.wikipedia.org/wiki/Technology_readiness_level
| goodpoint wrote:
| Familiarity supports popular language runtimes, tools, and
| idiomatic APIs experience deploying this technology to production
| today
|
| Stability follows a predictable release and versioning scheme
| (note: NOT frequent is fine and in some ways more desirable.
| security patches are always welcome of course.) biases for non-
| breaking changes easing long term maintainability publishes a
| regular changelog open-source and/or open-source backed service
| ideally public governance: roadmap, issue tracking, and decision
| making all visible
|
| Reliability can be trusted to work as expected; ideally does one
| thing well social proofs exist (careful!)
|
| Well understood limits, and trade-offs accessible docs objective
| benchmarks and/or published service quotas friendly community
| (Code of Conduct, blogs, chats, podcasts, etc.)
| friedman23 wrote:
| A lot of this boring technology talk just seems like an excuse
| not to learn something new.
|
| "X works fine why are we using Y?" "See Y doesn't cover every X
| use case perfectly, we should have stuck with X!"
|
| The arguments are predictable at this point. We'd still be using
| Jquery for developing frontends if this mindset was pervasive.
| aeternum wrote:
| If the ability to keep the site up is any indication, it looks
| like boring tech does not work as well in practice as the theory
| would have you believe.
| lmeyerov wrote:
| Missing two of the biggest:
|
| - hireability: large community of developers to hire from today +
| years from now
|
| - low risk of abandonment: long history of development, stable
| funding, and ideally many users+contributors from diff orgs using
| in commercial contexts
|
| Not easy for startups and new frameworks to achieve 'boring'
| status!
| miiiiiike wrote:
| This is where Angular dies. Great framework. There's almost no
| amount of money that you can pay someone to learn Angular in
| 2022.
| hughrr wrote:
| What is everyone gyrating around at the moment? I haven't
| touched front end for about a decade. It was jquery back
| then.
| lenzm wrote:
| I'd say React has reached boring by JS standards.
| macdonst wrote:
| Except for React introduces major changes with every new
| version causing thrash.
| kbrannigan wrote:
| I started a project with react! Stripped everything and
| went back to server side generated pages with sprinkles of
| jquery!
| wyager wrote:
| > large community of developers to hire from today + years from
| now
|
| I think this is a red herring. The thing that actually matters
| for most companies is marginal hireability. By the time you're
| big enough to worry about absolute hireability (because your
| hiring demands exceed the liquidity at the margins) you can
| create a hiring pool out of thin air (e.g. if google invents a
| new language and shills it a bit, tens of thousands of college
| students will learn it for free).
|
| If you're a small company and you're picking between Java and
| Elixir (or whatever) your concern should be "how hard will it
| be to hire 3 developers at a given quality level?", not "are
| there 1 million developers available?"
| k__ wrote:
| I wonder, how many engineers will switch their jobs because they
| have to work with boring tech?
|
| Sure, the stack you're using isn't everything and other parts of
| a project can be just as exciting. But I often heard engineers
| complain about their company being stuck in the past and they
| wish to use all the cool tech they see in the news.
| kingcharles wrote:
| I've worked at companies where many of the devs were not
| remotely excited about any new technologies and just wanted to
| do their 9-5 and get home to the wife and kids, which is a
| totally valid career choice. These guys just wanted to stick
| with what worked and what they knew. They LOVED boring.
| bob1029 wrote:
| > But I often heard engineers complain about their company
| being stuck in the past and they wish to use all the cool tech
| they see in the news.
|
| This is becoming my go-to filter for determining if I would
| want to hire someone in the first place. Hypothetically, if
| someone told me they left their prior job because they wanted
| to "use cool tech" on an interview, I would be providing a
| strong "No" input to the process.
|
| The honest reality is that a lot of people are doing a job they
| probably should not be doing. If you want to be really good at
| writing software for other people, you should enjoy delivering
| _experiences_ to your actual users. I find many developers can
| 't even enumerate who their end users are these days.
| k__ wrote:
| Sure, that's the best case scenario.
|
| In my experience companies, especially the small ones,
| struggle to hire engineers. So, they try to spice their
| positions up with some hot new tech.
| TacticalCoder wrote:
| Weirdly enough I do believe Clojure ticks the boxes from that
| checklist.
|
| It's familiar in that it both "supports popular language
| runtimes" (runs on top of the JVM or transpiles to JavaScript)
| and it's a Lisp dialect (or close enough) and Lisps have been
| around since a _very_ long time.
|
| It's incredibly stable: so stable some libraries commonly used
| haven't been updated in _years_. There 's also very little code
| churn inside Clojure's own codebase.
|
| It is very reliable.
|
| It's limits and trade offs are well known.
|
| Somehow I though my language of choice was "edgy" but I realize
| it may actually be "boring": a dialect from a very old family of
| language running on top of a boring tech (the JVM).
| darksaints wrote:
| I'd agree that clojure fits the boring tag, and that's a good
| thing. Unfortunately it's also dying. While many old libraries
| and tools are stable and functional, nothing new is really
| being created with it. The same couldn't be said for boring
| technologies like Java or Python.
| gregors wrote:
| Being acquired by a bank isn't exactly a bad thing for the
| language from a longevity perspective.
|
| https://www.cognitect.com/blog/2020/07/23/Cognitect-Joins-
| Nu...
| twobitshifter wrote:
| What about clojurescript?
| bachmeier wrote:
| My rule of thumb when someone says "Language X is dying" is
| to move on. I don't even use Clojure, and I can immediately
| come up with https://github.com/logseq/logseq and
| https://github.com/athensresearch/athens as funded
| companies making popular new products with Clojure.
| lacker wrote:
| I like Clojure, but it's really the exact opposite of the sort
| of "boring technology" that this post advocates. If MongoDB
| costs you 2 innovation tokens, Clojure costs at least 2,
| perhaps all 3.
|
| The cost of innovation is not so much in the core of Clojure
| itself, but that once your company gets larger, you will want
| to integrate with more and more things that have not put effort
| into Clojure compatibility, just because the language is not
| very popular. Also hiring.
| jayceedenton wrote:
| What is this 'Clojure compatibility' of which you speak?
| Seriously though, Clojure runs on the JVM so the entire Java
| ecosystem is available. There are ways to run an external
| process too of course. I can't really think of an example
| where 'Clojure compatibility' is something we would require
| people to have thought about.
| lacker wrote:
| A simple example is, let's say you're making a small web
| service. Are you going to use a Clojure framework or a Java
| framework via JVM compatibility? If you pick a Clojure
| framework, then all the subsequent choices you have to
| make, you'll run into the "non boring tech" issues. Has
| someone already built a GraphQL plugin, a plugin that
| integrates with the Twitter preview API, etc etc it depends
| on your project but you'll run into things. If you pick a
| Java framework, you'll end up running into a bunch of cases
| where you can't use the "normal solution" for that
| framework because you're running Clojure.
|
| It's not the end of the world or anything, and for a
| smaller project Clojure might be the perfect solution. But
| if it's something that you're trying to scale into a
| startup with dozens of engineers then you're probably going
| to pay a higher incompatibility cost for using Clojure.
| [deleted]
| [deleted]
| Scarbutt wrote:
| _you will want to integrate with more and more things that
| have not put effort into Clojure compatibility_
|
| The answer to that is to just use java interop.
| throwaway1777 wrote:
| Or even to have some clojure services and some Java ones.
| And then work toward more clojure over time if there's good
| reason to do it.
| [deleted]
| Cthulhu_ wrote:
| How about hiring though? If you have a vacancy for a Clojure
| developer, how many applicants could you expect?
|
| When it comes to programming languages, I'd stick to the top 10
| languages if your company isn't hip enough to attract a certain
| kind of developer on its own.
| radiator wrote:
| It almost sounds like you don't believe that developers can
| learn new languages.
| bsza wrote:
| If it's a language I'm not familiar with, I won't consider
| applying, so that's where the story ends in my case. I
| could be an outlier though...?
| Scarbutt wrote:
| The majority of companies want you to be productive on day
| one.
| exhaze wrote:
| That's pretty hyperbolic and also seemingly irrelevant.
| There are enough companies that don't have this
| expectation and give new engineers the time and space to
| become familiar with the company before setting any
| concrete performance goals.
| discreteevent wrote:
| Of course they can learn new languages. But it takes some
| time to become really proficient in a language. The
| question is how many languages do you want to support in
| your company? Because it's not realistic to think that
| developers will not need to move from project to project.
| And in fact when things get busy they may need to swap from
| one project to another and back on the same day. It's not
| ideal but that's life. The inefficiency of swapping between
| languages will often outweigh the efficiency of the new
| language.
|
| Google were notoriously strict for limiting languages at
| the start and I think it was very frustrating for some of
| the developers they hired. If I had a boring technology
| checklist then "Language we already use" would be top of
| the list.
| whakim wrote:
| Of course people can learn new languages, but:
|
| - A nonzero number of excellent potential applicants aren't
| going to work for your company because they don't want to
| invest their own development into learning the Clojure
| ecosystem deeply. (This might be somewhat balanced out by
| folks who are stoked to learn Clojure.)
|
| - Every non-Clojure person you hire will require
| significantly more ramp-up time. This can be a real problem
| for small companies where you lose quite a lot of expertise
| every time a senior developer leaves.
|
| - These problems compound for every "innovative" technology
| you add.
| pjmlp wrote:
| Learning a language is a piece of cake, learning the
| ecosystem is another matter.
| dchest wrote:
| Hiring more developers is overrated.
| gregors wrote:
| From what I heard, Nubank hired a good deal of Elixir
| developers when they aqui-hired Plataformatec. I suspect
| having functional programming experience matters more than
| having concrete Clojure knowledge. It definitely didn't seem
| to be a problem in this case anyway.
|
| https://medium.com/building-nubank/tech-perspectives-
| behind-...
| ithrow wrote:
| Hiring wasn't in the articles' checklist though ;)
|
| Valid point anyway
| olieidel wrote:
| When hiring / recruiting Clojure devs, there are quite a few
| second-order effects which are quite unintuitive.
|
| Clojure devs are much more senior - they've typically been
| burnt by at least one tech stack, often more (Java, JS +
| React, Fortran, Cobol, punching tape, etc.). Clojure devs
| also tend to be really passionate about, you guessed it,
| Clojure, which commonly turns out to be a good thing. People
| passionate about that level of language-detail tend to be
| meticulous about many other useful things, like choosing the
| right tools and building simple and maintainable
| applications.
|
| There's sometimes a slight tendency towards over-engineering
| which is understandable. People who dive deep into other
| programming languages and go through the pain of learning
| lisp sometimes tend to lose focus of the actual (business)
| problem to solve. But I wouldn't say this tendency is
| significantly higher than elsewhere. Still, sometimes, the
| pragmatism of a rails dev just churning out code is missed.
|
| Also, because Clojure jobs are scarce and there's a high
| number of "secret Clojurists" (people who code Clojure at
| night and secretly dream of using it at their day job), you
| actually get a much higher number of applicants than you
| would have estimated based on the most recent Stackoverflow
| survey.
|
| Also, you get a real shot at hiring rockstar devs. This is
| huge and cannot be overstated. If you're hiring for a
| standard JS / Python stack, you're suddenly competing with
| FAANG companies and their salaries. If you're hiring for
| Clojure, you're hardly competing with anyone. And you get a
| good pre-selection of senior devs. Like, those which were
| burned at a FAANG company, who finally came to their senses
| and now want to code Clojure. What's not to like?
|
| I guess a drawback would be that you couldn't instantly hire
| a local team of 100+ devs, even if you take secret Clojurists
| into account. But who would want to work at a place which
| hires 100+ devs in a short amount of time?
|
| (I interviewed around 200 people, many of them for Clojure
| roles, sometimes even comparing Python and Clojure applicants
| for the same role)
|
| Relevant talk: https://youtu.be/kNiGu_VaoTg?t=1566
| dwohnitmok wrote:
| All the points you're saying here are the usual arguments
| for choosing non-boring technology (I think I've seen this
| argument essentially verbatim for CL, Haskell, Clojure,
| Elixir, etc.), which is fine in isolation, but doesn't
| really fit in a thread about Clojure as boring technology.
| exdsq wrote:
| On the other hand you attract a certain kind of developer
| with those roles than generic languages.
| Steltek wrote:
| If you're using your tech stack as a hiring filter, it
| doesn't count as "Boring Technology".
| [deleted]
| exdsq wrote:
| No I appreciate that - my point is you can get better
| engineers that you might deserve at your startup by using
| a language like Clojure to entice them. I know people who
| work for a good discount if it's on a tech stack they
| enjoy and is fairly rare to find.
| pjmlp wrote:
| Nope, boring technology is using the platform system language,
| Java.
|
| Nothing extra to install, everything works out of the box, no
| need for FFI or incomprehensible stack traces.
| forgetfulness wrote:
| Clojure doesn't need FFI, neither does it need anything to
| run but the JVM, you package your application in a jar and
| run it the same as always, and you only write Java using your
| system editor and the JDK in introductory compsci courses.
| pjmlp wrote:
| It surely does, calls go both ways, and Closure doesn't
| understand everything introduced on the JVM since Java 8.
|
| Poor students, at least Blue/J.
|
| By the way, I already used Clojure in projects.
|
| Usually I only critic stuff I actually know.
| lmilcin wrote:
| The problem with Clojure is that it is too good. It gives you,
| the programmer, too much freedom.
|
| Most people do not have problems that require so much freedom.
|
| Most people do not know what to do with that freedom -- they
| don't have enough experience actually organising their
| applications.
|
| Most people benefit from using a language/framework that
| requires them or at least rewards them to put things in a
| certain way. For example Java Spring rewards people for
| following a certain application design -- you can break rules
| but then you are on your own and Stack[Exchange|Overflow]
| examples can no longer be copied/pasted directly into your
| codebase.
|
| As much as I love Clojure, every single corporate Clojure
| project I have seen in the past was an utterly unmaintainable
| mess.
|
| I have never actually participated in a Clojure project (I use
| Clojure mostly for rapid prototyping/PoC-ing), but what I
| figured is that Clojure requires minimum maturity from the
| developer and especially drive to be constantly simplifying
| things -- which is unfortunately very high bar. Most developers
| I work with / interviewed do not really understand what it
| means to refactor and simplify. Most people are only focused on
| the part of the work when they get something to produce
| expected values and everything else just isn't high priority in
| a corporate environment.
| [deleted]
| fouadf wrote:
| Node.js seems boring at this point
| midrus wrote:
| Not the 350+ libraries you need to pick to build anything
| useful with it.
| mrweasel wrote:
| Yet NPM is a little to exciting.
| mrkentutbabi wrote:
| What about between 2 boring technologies?
|
| For example I'm debating between Eleventy and Hugo (because I
| know both JS and Go, but not Ruby so I will skip Jekyll)
| chrisweekly wrote:
| Before you spend much time on a pure (thus limited) SSG, I
| recommend taking a close look at https://Remix.run. Remix
| supports a superset of Eleventy or Hugo (or Jekyll or even
| NextJS export). It's too new to be considered "boring", but it
| leverages OG web standards and defaults to web platform-native
| foundations. Given its provenance and the authors' bona fides,
| I'm betting heavy it sticks around for the long haul. I'm
| unaffiliated w the project, but I've been doing web-related
| things for a living since 1998, and for me Remix is a breath of
| fresh air and the successor to NextJS as my framework of
| choice.
| Zababa wrote:
| > Given its provenance and the authors' bona fides, I'm
| betting heavy it sticks around for the long haul.
|
| That's what people said for Redwood.js. One year later and
| it's mostly forgotten.
| mrweasel wrote:
| Boring is on a scale, and you need a reference to assess the
| level of boringness. Eleventy, Hugo and Jekyll are all a little
| to non-boring compared to ssg6 or just throwing txt files in
| www-root.
| egypturnash wrote:
| The truly boring choice for your blog is PHP and/or Perl.
| Wordpress, Movable Type, or possibly Textpattern if you are
| feeling a little edgy.
| Cthulhu_ wrote:
| The fact you worry about what language they're written in -
| while you shouldn't need to ever edit any of their code -
| already implies they're not boring and you're overthinking the
| decision already.
|
| Pick the one that gets you up and running the fastest, ideally
| one that doesn't rely on you installing additional runtimes.
| 9dev wrote:
| In principle you're absolutely right, but Hugo actually comes
| with lots of strings attached due to their choice of Go, like
| having to use Go templates for example - which can be weird
| if you don't have a Go background. The more elaborate
| constructs you're trying to build, the more you need to
| research how the Hugo Go runtime works to sort out quirks.
| erikpukinskis wrote:
| Flip a coin, try the first one out, and if anything pops up in
| a few days that makes you think the other might be more
| suitable, evaluate the other one.
|
| I recently started experimenting with Snowpack for JS build. I
| realized it doesn't do sourcemaps very will so I grabbed
| Parcel. That worked great but doesn't have a testing story and
| Vite has a couple options there. Vite has been good.
|
| It was work to evaluate each of those and switch between them.
| But not that much work really since I hadn't committed a huge
| codebase yet. But it was worth it because now I know why you
| might choose one over the other.
|
| Granted the "boring" choice would be Webpack.
| ithrow wrote:
| This a good advice for dealing with 'decision paralysis'
| which can make you waste more time than just trying out the
| options.
| mrkentutbabi wrote:
| Good advice thanks
| foobiekr wrote:
| I do this. But 1d20 / options. Crit fail means ignore for a
| week otherwise divide up the space evenly and extra slots
| mean re-roll. Having the option to punt is useful.
| dsr_ wrote:
| Compare them in your particular scenario. Only you know what is
| important to you. If choosing for a company, ask the people who
| will have to work with it.
|
| Maybe one has more responsive developers, or a more helpful
| community.
| wrnr wrote:
| I don't consider it my job to do the same thing in the same way
| to accomplish the same thing.
| lukemunn wrote:
| Interesting to see a few posts on HN recently advocating for
| 'dumb' or 'boring' tech as I'd been writing an article on 'dumb
| technology' along the same lines. Comments welcome.
| https://www.researchgate.net/publication/358248465_Dumb_Tech...
| ape4 wrote:
| I hate to say it, but in many ways Windows checks many boxes -
| its backwards compatible for decades. Programs from 30 years ago
| still work fine.
| mrweasel wrote:
| Hate to agree, but yes. A C++ application using the APIs
| provided by Windows is pretty much unbreakable by time.
| mixmastamyk wrote:
| The core is fine, it's being at the whim of MS's hostile
| marketing and sales departments that are decidedly not boring.
| jalanco wrote:
| One day, if we wait long enough, The Boring Company technology
| will be boring technology.
| heipei wrote:
| Personally I believe that even more important than picking boring
| technology is limiting the number of different technologies in
| your tech stack. That will allow you to collect more best
| practices, build better tooling and monitoring and develop
| operational experience in those few technologies than if it was
| spread across multiple similar stacks.
|
| Example: React is great for starting with smaller and/or
| progressively enhanced websites, but if you were to develop a
| large monolithic SPA you might benefit more from something like
| Ember. However it would be better to use one stack which can
| cover both use-cases, so you should probably go with React for
| both, otherwise you'll forever be rewriting the same code for
| both stacks and figuring out build and tooling issues twice.
|
| Another example: You might need a lightweight message queue for
| smaller background processing needs, and you might also need a
| proper distributed log. The former could be solved by any number
| of queues, while the latter calls for something like Kafka. If
| Kafka can also reasonably cover the first use-case you should try
| to use it for both.
| [deleted]
| dwohnitmok wrote:
| I think commentators are missing that a big part of boring
| technology is, well, that it's _boring_. If developers are
| excited to _use_ that technology, instead of just thinking "meh
| just another one of those companies using X" then it's probably
| not boring.
|
| If your technology gets developers excited then it's not boring.
|
| As per the original article that introduced the term, that
| doesn't mean that it's a priori a bad thing, but it does mean
| that the bar for the other things it brings to the table needs to
| be higher and that most startups only get a limited number of
| technologies to be excited about.
| sedatk wrote:
| > biases for non-breaking changes easing long term
| maintainability
|
| So, not ElasticSearch.
| mrweasel wrote:
| Or Kubernetes
| ChrisArchitect wrote:
| Hey OP or mods, could you please _update this link_
|
| Dunno where the staging server came from
|
| https://blog.begin.com/posts/2022-01-27-the-boring-technolog...
| andrewf wrote:
| I'm years out of date on this stuff, but I note the staging URL
| has found its way into Google as well, you might be able to fix
| that up by adjusting the <link rel="canonical"
| href="https://blog.staging.begin.com/..." /> to point to the
| authoritative URL even when the page is on the staging server.
| dang wrote:
| Ok, changed from
| https://blog.staging.begin.com/posts/2022-01-27-the-
| boring-t.... Thanks!
| macdonst wrote:
| Whelp, I'm an idiot for copying the wrong url. I don't seem to
| be able to edit the url, only the title.
| hughrr wrote:
| Please also add _"doesn't auto close three million ignored GitHub
| tickets"_ every week, the true quality metric these days.
| antod wrote:
| Well, they were _boring_ tickets in the CADT sense.
|
| Seriously though, probably the difference being a _boring_
| project and being a _bored_ project.
| xupybd wrote:
| I think F# meets all of the checklist items for me. I'm still not
| going to consider it boring as it's too esoteric.
| Steltek wrote:
| This article would be enhanced with concrete examples. The
| "Boring Technology" argument is hard to attack because it's an
| opinion, an ideal. It's a good ideal, mind you, but it has the
| problem of being different for each person, even if they're all
| on the same team looking at the same use case.
|
| Another good extension to the topic would also be defining when
| Boring Technology becomes Ancient Technology. You need to hit
| that middle of the tech curve where it's understood and stable
| but also still being maintained and keeping up with modern needs.
| [deleted]
| deltarholamda wrote:
| I think the flexibility of the ideal is part of what makes it
| so attractive. "Boring" may mean some pretty cutting-edge
| technology because your team is so thoroughly steeped in it
| that they know it back to front.
|
| For me, "boring" means avoiding things like Kubernetes because
| it's an ecosystem with which I am woefully unfamiliar and I can
| more or less achieve with other (possibly less efficient)
| means.
|
| Ted Dziuba made a point a while back that the three tools for
| systems engineering are money, time, and code, and they should
| be used in that order. It's a sort of shorthand for "boring" to
| just buy a bigger server, or spend the time to leverage
| existing and know Unix tools, and then if all that fails, use
| some gimcrack new tech to solve your problems.
|
| (Though, I'd say that the biggest impediment to leveraging
| "boring" technologies is correctly determining what your
| problem is. Sometimes we focus on the wrong metrics, or the
| right metrics at the wrong time, and that skews our decision
| making.)
| 62951413 wrote:
| A boring technology is one with which a large number of
| developers have previous production experience with. Or probably
| even "of the developers you can realistically expect to hire".
| ghughes wrote:
| Better yet, hire developers who enjoy and excel at selecting
| and utilizing emerging technologies that will be a better long-
| term fit for the problem at hand. This is of course more
| difficult, but makes for a better team and product. I want my
| competitors to be afraid of technology and to de-prioritize
| hiring generalists.
| wyager wrote:
| > friendly community (Code of Conduct, blogs, chats, podcasts,
| etc.)
|
| In my experience, most of these things negatively correlate with
| stuff I actually want (like software quality or stability). It
| indicates a software ecosystem that exists mostly as an ersatz
| social outlet for a certain kind of person. The best softwares I
| use tend to have none of this stuff - maybe just a mailing list
| and a bug tracker.
| Jensson wrote:
| Yeah, boring technology requires boring owners to ensure that
| stuff like Python 3 wont happen.
| mwcampbell wrote:
| I was surprised to find this published on begin.com, which offers
| an app deployment platform based on AWS Lambda. So are Lambda,
| API Gateway, and friends considered boring now?
| tikhonj wrote:
| Nobody gets fired for choosing IBM, and nobody gets fired for
| choosing AWS.
|
| The corollary that's missing, of course, is that they often
| _should_ get fired--but popular (sorry, "boring") choices have
| a momentum of their own.
| zdw wrote:
| They may not be, but cgi-bin, webservers, and monitoring via
| grep /var/log/www/*.log are.
| Cthulhu_ wrote:
| You say that, but setting up a LAMP stack from scratch is
| more involved than just yeeting something onto GCP these
| days.
| mschuster91 wrote:
| On Debian, a LAMP stack should not take more than an hour
| to set up from scratch.
| erikpukinskis wrote:
| Is lambda really that different from any other server
| technology?
|
| It's just a container that you have to boot and it handles web
| requests, right?
|
| They boot fast, so for a low traffic site you can worry less
| about cold start, is there any other difference with any other
| containerized web server?
| travisjungroth wrote:
| Yes. In theory it would be the same but practically there are
| lots of gotchas. For a simple example, having a calculated
| cache on startup that five seconds would be fine on a
| traditional server but not on lambda.
| brianleroux wrote:
| hello author here! personally find AWS extremely boring, very
| mature and stable. well known limits, and tradeoffs.
| [deleted]
___________________________________________________________________
(page generated 2022-01-31 23:01 UTC)