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:
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.
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.
We had a very complex application that would take care of hundreds of events per second, doing all sorts of calculations on top of that. It would get stuck frequently in GC cycles due to huge number of objects processed in memory and developers unconstrained resource usage.
We switched it to ZGC, only by changing startup options, and the application was like a brand new thing. Very responsive and zero GC issues.
Rewriting it in C++/Rust would take many months and even more $$$, and no one could guarantee it would work better.
With some variations, this setup describes my entire career as software engineer so far. Reading Hackernews, for the longest time, I had this lingering feeling of knowing nothing or not the right things.
Now, I know that my experience isn't just the norm for a great number of developers, at least in Europe, but also a reasonable choice. If there is no need to do something fancy, don't do something fancy. Not in a professionell business environment. There are zero upsides for the business.
The JVM is vastly underestimated. I think the root cause is an image problem, stemming from a combination of bad programming practices in the past (getter/setter bloat, Factories for everything and unnecessary object orientation) and heavy and outdated frameworks such as Spring, JSF and others.
Would just like to toss in CLR for folks who like .NET. You get C# which is great (but I'm biased), and F# if you have a functional paradigm. Both EF and Dapper can pretty easily hook into Postgres. I'm also partial to Azure over AWS so there's obviously a bias toward C# over something like Java there. There are similarly great ES/CQRS libraries for .NET - I'm not sure about CDC on the Postgres side but they exist for SQL Server if you're using that.
Unfortunately all programming languages are flawed. It's kind of funny how we still have no programming language that does everything to a satisfying degree instead of having one major wart that always means that a different problem requires a different programming language.
There are not many languages with a lean runtime. The JVM needs a lot of memory even if you have 0 bytes of heap usage. Javascript applications are often tied to electron.
There are not many fast languages that do not cause security issues or cause hard to debug segfaults. The two obvious choices are Rust, Java (or C#) and maybe Go. I personally set the cutoff point for fast enough to be Javascript with v8. Not everything needs to be fast enough to be used for a game engine but at the same time I don't want to CPU or user time on gross inefficiencies.
There are not many modern languages that everyone agrees to use. Javascript is the pinnacle of this because people are forced to use it. The JVM suffers from having too many languages. Kotlin is the only winner but I am still bitter about that one JVM language that died. I don't know why but Rust is one of the most hated languages on HN.
There are not many easy to learn languages. C++, Rust, Haskell, Scala all tend to suffer from the ability to write convoluted code bases that nobody understands. People become experts within their own small islands. Java EE also had a phase where everything was done with impenetrable xml files that were getting closer and closer to turing completeness. Java and Go are both a direct response to C++ being too complex.
All easy to use languages (primarily JVM languages but also many interpreted languages) fail because they are not fast and lean and nobody uses them.
All fast and lean (=low level) languages fail because they are too complicated or suffer from security problems.
The answer? I don't know. I thought graalvm was going to solve this with it's native image mode but my preferred JVM language doesn't run on it. I'm hoping that Java will be good enough if I'm going with a slightly non standard setup (immutables). The lack of reflection means that you have to avoid a lot of libraries. Ecosystem advantages are disappearing if you go down this route.
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.
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".
>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).
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.
I think in those scenarios you need to isolate the risky and exciting bits through APIs etc and build the rest of it using boring tech. I know of a company who failed miserably on delivery after they completed their ML risk engine and blew the budget trying to get a piece of shit Angular and nodejs front end for it working.
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.
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...
"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
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.
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.
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.
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.
JetBrains as a massive user of Java has a vested interest in making sure Kotlin is pleasant to use (and it's first party nature on Android helps here as well) and interops really really well with existing Java code (since that is their own use case).
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?
Yeah, Swift is great. Also enjoy using it. There are problems, but it is getting better. For example, now with Swift 5.3, you can have packages with resources. In particular this means you can easily (well, if you stitch together various blog/stackoverflow posts) bundle Metal shaders with your packages now, which is a huge win for the work that I am doing.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
[+] [-] jsnell|5 years ago|reply
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=20323246
https://news.ycombinator.com/item?id=23444594
[+] [-] bjeds|5 years ago|reply
[+] [-] mromanuk|5 years ago|reply
We always can discuss it a little bit longer
[+] [-] amzans|5 years ago|reply
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.
[+] [-] partomniscient|5 years ago|reply
Do not deny it to them or belittle those that provide said opportunity. Your past is not their past.
[+] [-] jpgvm|5 years ago|reply
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.
[+] [-] dig1|5 years ago|reply
We had a very complex application that would take care of hundreds of events per second, doing all sorts of calculations on top of that. It would get stuck frequently in GC cycles due to huge number of objects processed in memory and developers unconstrained resource usage.
We switched it to ZGC, only by changing startup options, and the application was like a brand new thing. Very responsive and zero GC issues.
Rewriting it in C++/Rust would take many months and even more $$$, and no one could guarantee it would work better.
[+] [-] kharak|5 years ago|reply
Now, I know that my experience isn't just the norm for a great number of developers, at least in Europe, but also a reasonable choice. If there is no need to do something fancy, don't do something fancy. Not in a professionell business environment. There are zero upsides for the business.
[+] [-] emsy|5 years ago|reply
[+] [-] dmos62|5 years ago|reply
Don't forget the low-latency GCs, like ZGC:
https://wiki.openjdk.java.net/display/zgc/Main
[+] [-] pc86|5 years ago|reply
[+] [-] imtringued|5 years ago|reply
There are not many languages with a lean runtime. The JVM needs a lot of memory even if you have 0 bytes of heap usage. Javascript applications are often tied to electron.
There are not many fast languages that do not cause security issues or cause hard to debug segfaults. The two obvious choices are Rust, Java (or C#) and maybe Go. I personally set the cutoff point for fast enough to be Javascript with v8. Not everything needs to be fast enough to be used for a game engine but at the same time I don't want to CPU or user time on gross inefficiencies.
There are not many modern languages that everyone agrees to use. Javascript is the pinnacle of this because people are forced to use it. The JVM suffers from having too many languages. Kotlin is the only winner but I am still bitter about that one JVM language that died. I don't know why but Rust is one of the most hated languages on HN.
There are not many easy to learn languages. C++, Rust, Haskell, Scala all tend to suffer from the ability to write convoluted code bases that nobody understands. People become experts within their own small islands. Java EE also had a phase where everything was done with impenetrable xml files that were getting closer and closer to turing completeness. Java and Go are both a direct response to C++ being too complex.
All easy to use languages (primarily JVM languages but also many interpreted languages) fail because they are not fast and lean and nobody uses them.
All fast and lean (=low level) languages fail because they are too complicated or suffer from security problems.
The answer? I don't know. I thought graalvm was going to solve this with it's native image mode but my preferred JVM language doesn't run on it. I'm hoping that Java will be good enough if I'm going with a slightly non standard setup (immutables). The lack of reflection means that you have to avoid a lot of libraries. Ecosystem advantages are disappearing if you go down this route.
[+] [-] LordHumungous|5 years ago|reply
I would choose a NoSQL store for something that needs to scale.
[+] [-] solatic|5 years ago|reply
[+] [-] theshrike79|5 years ago|reply
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".
[+] [-] pydry|5 years ago|reply
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|5 years ago|reply
[+] [-] artemonster|5 years ago|reply
[+] [-] simplyinfinity|5 years ago|reply
[+] [-] madeofpalk|5 years ago|reply
[+] [-] qz2|5 years ago|reply
[+] [-] tannhaeuser|5 years ago|reply
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.
[+] [-] maerF0x0|5 years ago|reply
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...
[+] [-] jb3689|5 years ago|reply
* 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|5 years ago|reply
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|5 years ago|reply
[+] [-] ChrisMarshallNY|5 years ago|reply
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.
[+] [-] Veen|5 years ago|reply
[+] [-] noir_lord|5 years ago|reply
JetBrains as a massive user of Java has a vested interest in making sure Kotlin is pleasant to use (and it's first party nature on Android helps here as well) and interops really really well with existing Java code (since that is their own use case).
[+] [-] keyle|5 years ago|reply
[+] [-] auggierose|5 years ago|reply
[+] [-] LordHumungous|5 years ago|reply
Exactly. When people say "You should work on boring tech." my thought is "Mmkay, sure thing buddy, you do you."
[+] [-] WilTimSon|5 years ago|reply
[+] [-] bamboozled|5 years ago|reply
“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.
[+] [-] _urga|5 years ago|reply
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|5 years ago|reply
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.
[+] [-] spacekitcat|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] fendy3002|5 years ago|reply
- 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
[+] [-] silvestrov|5 years ago|reply
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|5 years ago|reply
[+] [-] vendiddy|5 years ago|reply
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.
[+] [-] jillesvangurp|5 years ago|reply
[+] [-] greenkey|5 years ago|reply
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.
[+] [-] nikon|5 years ago|reply
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|5 years ago|reply
[+] [-] ulisesrmzroche|5 years ago|reply
[+] [-] nickjj|5 years ago|reply
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/
[1]: https://nickjanetakis.com/blog/talking-with-52-devs-about-bu...
[+] [-] forgotmypw17|5 years ago|reply
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.
[+] [-] scanr|5 years ago|reply
I like the idea of people in a room arguing about why their tech choices are the most boring.