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 hi…
Boring Technology Checklist
51–60 of 119 posts
Re: Boring Technology Checklist
#52It'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.
Re: Boring Technology Checklist
#53Earlier quoted context omitted.
On the other hand you attract a certain kind of developer with those roles than generic languages.
If you're using your tech stack as a hiring filter, it doesn't count as "Boring Technology".
Re: Boring Technology Checklist
#54Re: Boring Technology Checklist
#55Re: Boring Technology Checklist
#56Missing 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!
This is where Angular dies. Great framework. There's almost no amount of money that you can pay someone to learn Angular in 2022.
Re: Boring Technology Checklist
#57In 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.
Re: Boring Technology Checklist
#58Missing 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!
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?"
Re: Boring Technology Checklist
#59Weirdly 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 ins…
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 becau…
Re: Boring Technology Checklist
#60Stability 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.)