10 ms·

Choose Boring Technology (2018)

195 points by signa11 3y ago

honkycat 3y ago
I've always hated this article and the "boring programmer" shtick. I've always found the "boring programmer" thing pretentiousness trying to disguise itself as humility.
ksec 3y ago
Previous Discussions. 367 Comments: https://news.ycombinator.com/item?id=26211721 https://news.ycombinator.com/item?id=26211721 84 Comments: https://news.ycombinator.com/item?id=31558887 https://news.ycombinator.com/item?id=31558887
- dang 3y ago
  Thanks! Macroexpanded: Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=31558887 https://news.ycombinator.com/item?id=31558887 - May 2022 (83 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=30389591 https://news.ycombinator.com/item?id=30389591 - Feb 2022 (13 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=26211721 https://news.ycombinator.com/item?id=26211721 - Feb 2021 (361 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=25322651 https://news.ycombinator.com/item?id=25322651 - Dec 2020 (204 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=23444594 https://news.ycombinator.com/item?id=23444594 - June 2020 (282 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246 - July 2019 (344 comments) Choose boring technology - https://news.ycombinator.com/item?id=16677583 https://news.ycombinator.com/item?id=16677583 - March 2018 (1 comment) Choose Boring Technology - https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215 - March 2015 (212 comments)
  - ChrisArchitect 3y ago
    (2015) up top
    - dang 3y ago
      The linked page seemed to be a talk from 2018, not the essay from 2015, so I used that year. If that's wrong, we can correct.
claytonjy 3y ago
Is boring technology even an option in high-velocity fields like ML/AI? I can pick boring databases and boring servers but when it comes to model architectures, model weights, GPUs, serving frameworks, etc. there's been such massive improvements lately that it doesn't feel like anything has settled enough to be "boring". If I need a language model, or an image classifier, or an ASR model, there are older options which might be "boring", but they're not nearly as powerful as the latest options. Does choosing boring ML tech mean sitting out on massive recent advancements?
- dgrin91 3y ago
  99.999...% of us don't work or seriously touch in AI in any way. At best you make an API call to something that might do some AI, but at that point its just another service. So for the vast majority of people doing dev work, boring choices are correct. I've had a lot of junior devs come to me with proposals for microservice architectures that can autoscale, be orchestrated, have 0 downtime with red/blue deployments, etc, etc, when at the end of the day it could be done with a boring, single server (plus second for resiliency, but not needed for scaling) with just a few endpoints. It will be done much faster & simpler, which means it will be cheaper and less likely to fail. My guess is that the same is true in a lot of AI work. Yes there is core stuff that needs to be performant, scalable, and modern, but I'm sure there is also a ton of boring old regular internal corporate infra that can be done 'boring'.
  - threeseed 3y ago
    The first approach will be significantly cheaper if using the cloud. It allows you to use spot/ephemeral instances and scale down capacity to almost zero cost without any loss in availability. Single server in the cloud is great for dev environments and if you don't care about uptime. But given that poor uptime is toxic for customer retention only incompetent businesses would deliberately not choose to use something better suited. Especially when it's so much cheaper.
    - lelanthran 3y ago
      > The first approach will be significantly cheaper if using the cloud. Only if you're regularly scaling down to zero (AKA too few paying customers to stay in business). > only incompetent businesses would deliberately not choose to use something better suited. There's a time and place for both approaches. If you're serving anywhere near the number of users needed to show a profit, spot instances are extremely expensive.
andrewstuart 3y ago
edit: Apparently "choose boring technology" is just clickbait, and in fact the guy advocates for all the nuanced technology selection advocated here.... so errr, apparently he in fact is saying "don't chose boring technology" or something, whatever. I completely disagree with almost any blanket philosophy on technology. Don't choose boring technology. Choose technology that suits the context: * choose what you like for personal projects * choose tech your team has the skills with * choose tech that won't be a problem to recruit people for (I'm looking at you, Ruby On Rails) * choose tech that gets the job done * choose tech that the industry is moving towards * choose tech that levels up your team's skills and makes them feel excited that they are learning and advancing * choose tech that allows you to meet the priorities of the project (your project does, define priorities, right. right?) security/availability/maintainability/performance/compatibility/whatever * choose tech that ensures your team and company won't be left behind when market skills move on * choose the cutting edge if you think that's the right choice for some reason It seems pointless to me to say "choose boring technology".
- gfodor 3y ago
  It turns out that it’s impossible to reasonably title any talk or article without it being considered a blanket statement. This is why you attach the talk or article to the hyperlink so people can continue understanding more of what you are saying.
  - avindroth 3y ago
    Well, this is just clickbait. Choose boring technology means sth pretty concrete for someone without context. It’s not that you can’t reasonably title it. It’s that you can’t reasonably title it to generate views. I understand the sentiment, but then one should expect criticism of the schism between title and content.
    - gfodor 3y ago
      "Clickbait" has been apparently watered down to the point of meaninglessness then. You title things to get people to want to read them if you're sharing information you think is important. The term "clickbait" is typically used to refer to false and misleading titles to generate ad revenue for garbage content.
deleted 3y ago
[deleted]
Pannoniae 3y ago
While I see how this makes sense, I don't like this. If most people follow this strategy, we will end up with utter stagnation, or even devolution. "Boring" technology also has many hidden costs - most importantly, opportunity costs of not having several times higher productivity due to the warts and quirks of the boring tools. Sure, with enough practice one can work around them but every backwards issue takes a good chunk of productivity out of the project. I get the argument of "if it's not mainstream, where will we find programmers" - but that's more of a cultural issue of wanting expert programmers out of the box instead of investing in them and training them. Ultimately, this line of thinking is like saying 640K RAM is enough for everyone. Sure, you might say C++ and Go is enough for everyone, but there are many unrealised gains left on the table.
- gfodor 3y ago
  The talk doesn’t say to always choose boring technology. But you might think it does if you read three words and wrote a comment in response to them.
  - Pannoniae 3y ago
    This was the second time I've read that talk. Please don't accuse me of not reading it. As all of us, it might be that I completely overlook, or interpret something entirely differently or outright wrongly, but I think this is entirely uncalled for. Edit: I kind of see what you mean now. My paragraph about hiring was somewhat tangential. I am sorry.
    - gfodor 3y ago
      No worries!
- jpgvm 3y ago
  That isn't how any of this works. We don't get new innovative databases because of small startups deciding they want to roll their own database as part of building their new fangdangled AI thing. We get new innovative database either by new innovative database companies that rightfully spend their time and effort trying a new idea in the space or out of huge companies with R&D budgets to build such things, like Spanner. Startups choosing boring tech for everything that isn't their core/critical innovative area should actually accelerate innovation by focussing effort more efficiently. I do agree that the whole hiring aspect of it is hot garbage though. If Haskell is the best fit for what you are making and is considering boring in your field (say you are doing verification) then it makes perfect sense to use it even if the pool is smaller because a) people that stick to Haskell despite its difficulties probably have more passion for the craft and b) it's way more likely someone that knows Haskell has some exposure to your field, verification in this case. Same can apply to lots of "niche" languages/tools/etc. Boring is relative to what you are working on. I build distributed systems primarily. For me boring is Java. I imagine C++ is boring for game devs/GPU folks. etc.
freelanceTA 3y ago
I want to choose tech that has the least amount of maintenance. For example I had to build a web app thing for something I'm doing. The many frameworks available are of course trivial to string together but now I'm looking at a huge amount of dependencies all that require a lot of maintenance. I went with avoiding all but the the most critical libraries for authentication but is there a better way? I found even writing in OCaml and generating js into a docker file to be hosted by someone else who maintains node.js was actually less maintenance than me using any existing frameworks
- chadcmulligan 3y ago
  I prefer jQuery and jQueryUI - actually I go one further and use the devextreme components so I have paid support (outrageous I know) for spa's or something like umbraco for CMS but they are very unsexy and old. Delphi for cross platform applications, but try and sell that as a development platform :-D I think the big advantage of this sort of stuff is you have a million debugged and working examples to pick from and people who know them inside out. Edit: I watch the kids trying to figure out how to release things on docker with their multiple git branches and merges, and re-engineering their microservices frameworks, and each time I die a bit inside. This was all done so long ago, why continue to make it harder. Now I'm not talking something google scale, but something with a few hundred users and maybe 20 concurrent, why would you do this, sigh.
  - kyawzazaw 3y ago
    resume driven development
- em-bee 3y ago
  i found the key in reducing maintenance overhead is to avoid complex build tools that claim to manage your dependencies and use frameworks that don't frequently break compatibility.
mikece 3y ago
The points often lost here is that (1) this advice is aimed at startups, and (2) the whole concept of "innovation tokens." Any successful business is going to solve some problem which is probably not so obvious and that takes innovative thinking. If you're spending too much time trying to be innovative with your tech stack then you're NOT innovating on your specific difference as a business, and that hold you back (or could bankrupt you). All of that said, today's tech landscape is far less edgy than the early days of cloud, NoSQL, and NodeJS. I'm not even sure what tech is out there that would qualify as "spending your innovation tokens" other than AI.
- eternityforest 3y ago
  Blockchains, making your own JS framework/language/static site generator/MQTT alternative/etc, building a desktop GUI toolkit, making your own VCS, retro hipster type stuff like handwriting HTML with no templates or JS, or using Linux without some kind of configuration management system...
- chii 3y ago
  > I'm not even sure what tech is out there that would qualify as "spending your innovation tokens" other than AI. that's why they call it innovating. If you knew already, then it wouldn't be innovating, since it's not the innovation that's new.
- jpgvm 3y ago
  Biggest time wasters and innovation token consumers IMO is third-party vendors, especially shiny startups/products. Don't waste your time, money and energy being someone else's guinea pig, you need to be focused on your business problems. Bigger companies that have engineers and resources to waste can try these out for you and eventually that startup you knew a few years ago will either be successful and ready for you to use or dead and you will be glad you didn't waste the effort. Same goes for propropertary cloud services that have no business being proprietary. Biggest culprits here are data silo-ing lock-ins like DataDog, avoid like the plague. Use the standard off the shelf tools for everything you can, OSS may require slightly higher upfront integration costs in some cases, less than you think though, sometimes it's substantially faster due to integrations. Generally speaking if a project has been around long enough folks have already encountered every problem and shared every solution. If you are stuck with some proprietary vendor for some important part of your stack and you are hitting an edge condition you had better hope you are a big enough fish for them to care (hint: You aren't). I guess at the end of the day keep yourself off the Kool-Aid, ignore marketing speak and always ask hard questions of things and you will avoid innovation token sinks.
lmm 3y ago
He writes all this philosophy and then concludes with using PostgreSQL instead of mongoDB or nodeJS (? I'm not sure how that was in the same category). PostgreSQL is the opposite of boring technology; I've been using it for over 10 years and am still discovering new and surprising features with new and surprising failure modes; PostgreSQL today is very different from PostgreSQL 10 years ago, but setting it up for true master-master replication is still a clusterfuck and you still have zillions of moving parts in real world use. I'm lead inevitably to the conclusion that philosophising about tech choices and principles is pointless. Everyone will nod and agree with the principles and tradeoffs and then pick their personal pet technology anyway.
- gaganyaan 3y ago
  You're kind of missing the point, unless you're saying that regular PostgreSQL also has interesting failure modes. PostgreSQL clustering may not be boring technology, but that just means you scale up instead of out. If you run out of headroom for scaling up, that probably means you're successful enough that you can take a look at non-boring technology.
- kyawzazaw 3y ago
  doesn't that mean you are now ready for a new innovation token, which is inline with the written philosophy?
- ksec 3y ago
  I would have thought MySQL would be a better fit for boring technology.
  - gaganyaan 3y ago
    Given that the author compared MongoDB vs PostgreSQL, I think the technology in question is SQL vs NoSQL, not a particular flavor of SQL vs the other.
- simonw 3y ago
  PostgreSQL is absolutely boring technology. What makes it boring is: - people have been using it for decades, for all kinds of different things - this means that any problem you run into, someone else will have seen before - and will have talked about it online - you're not going to be using it to solve a class of problems that no one else has used it for before
LAC-Tech 3y ago
I feel like this has been misunderstood for years. I note this paragraph: But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down. I understand F# more than I understand PHP. By the articles definition, F# is 'boring', and choosing to do something in PHP would be using up an innovation token.
- hooverd 3y ago
  If it works you and/or your org, then yeah.
- joshuahutt 3y ago
  Another thing to keep in mind is the size of the candidate pool. There's a lot fewer F# devs than PHP. Can make hiring a bit trickier.
  - worthless-trash 3y ago
    And I was under the impression that coders were thought of as replaceable cogs in a machine, one just as good as the next.
  - jpgvm 3y ago
    This is almost never a bad thing. It means you have fewer people to compete with when advertising a position and the people that use a niche technology generally have more passion for their craft.
    - dukeyukey 3y ago
      Although it also delays hiring - I work for a startup using Kotlin, and we've had maybe three candidates _ever_ who have used Kotlin beyond hobby projects. And I was one of them!
  - photonbeam 3y ago
    You might get less volume, but you can use this as an advantage
fnfjfk 3y ago
This article gets posted a lot, but I find it a little unsatisfying. I think it’s because it’s pretty vague about what “boring” means exactly, so it’s the kind of statement most can agree with, without it actually being a very strong statement. It’s not wrong per se, don’t choose some technology posted for the first time yesterday. But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea. The specific languages it calls out are Python and PHP, which IMO are bug-prone languages with serious performance/efficiency implications. Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet). I would say more important is “write boring code”, and it is easier to write boring to-the-point code in modern languages without implicit null references, with sum types for modeling mutually-exclusive data, and with as many other common pitfalls statically eliminated as is possible.
- kyawzazaw 3y ago
  > But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea. But isn't the point that if you run into this much issue for the initial choice, you are now ready to use an innovation token and switch to a different one? > Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet). At that point with all the financial resources, they can consider to rewrite/migrate. Thus, at the start, chose boring technology. Even at a big company, retraining or hiring people proficient in Rust will probably cost more than continuing to use C++ codebase and people.
  - hgomersall 3y ago
    Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. We dropped C for Rust in a systems language context and technologically it was a fantastic choice. I guess some of the benefits of a language switch could have been realised with C++, but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Rust held far more appeal and in hindsight has helped us provided fantastic stability in our software whilst developing very rapidly.
tuyiown 3y ago
Looks like a very convoluted way to say that you should avoid mistakes, but with confusion between familiarity and in depth analysis. Worst surprises generally comes from non verified expectations, and ends up to hard to workaround problems that becomes clear in hindsight «It never really worked that way». You have better chances to avoid that with tech you are familiar with, but the only real way is to verify how the thing is built, and on what principles, confront that to your knowledge, and if it aligns you have greatly improved the chances of things going smoothly. Since people are generally not rational and rarely do those checks, when working with a team, going with familiarity is the safe route.
MichaelMoser123 3y ago
and who defines what is boring?
- worthless-trash 3y ago
  This is the big question.
- em-bee 3y ago
  boring is what you already know and don't need to spend a lot of time learning, or, if you don't know any, then it's what is widely known and well documented.
  - MichaelMoser123 3y ago
    Already know? I think that any technologies can pose a non boring challenges. These tend to happen when a technology is used at scale, or with an unusual use cases. Look at 'boring' php, facebook was using this language at scale, so they had to develop a just in time compiler for the whole thing. Python didn't have that problem, so it still doesn't have a just in time compiler (for the default interpreter) Also look at all the changes and action in the JDK (ever since JDK11). Is that also boring?
    - em-bee 3y ago
      I think that any technologies can pose a non boring challenges. These tend to happen when a technology is used at scale, or with an unusual use cases. yes, that is true but i think that supports the point: use boring tech to solve interesting problems.
      - MichaelMoser123 3y ago
        i think it that the definition of 'proven' technology smells of silos: if you come from the Java world, then everything else is not relevant, same for php/python, same for the nodejs world.
TurboHaskal 3y ago
I mean I would love writing Ada and Common Lisp at work but my hipster CTO wants me to use Go and TypeScript.
philippta 3y ago
What is the boring technology for frontend development?
- LAC-Tech 3y ago
  The one you know the best.
- somesortofthing 3y ago
  Though it was far less clear when this article was written than it is now, if you're starting from scratch on a webapp today it's hard to go wrong with React.
  - em-bee 3y ago
    there are a lot of voices against react too, so i would be careful. react is a good choice in that its downsides are well known and documented, so at least you can make an informed choice. but i would cast a wider net and look at svelte, vue and angular as well. personally i use aurelia, but it being less popular means that less people write about it so there may be hidden downsides. i am already familiar with it which is sufficient to qualify as boring for me. and i am also solving boring problems which allows me to spend my innovation tokens on my tech stack.
- petepete 3y ago
  HTML and CSS. Boring, reliable, accessible, extendable. Only reach for JavaScript when it's actually required - which is less often than the modern web would suggest.
  - shepherdjerred 3y ago
    This is not at all what the article is advocating for.
- shepherdjerred 3y ago
  React and Vue probably qualify as a boring tech, but you could also use traditional server-rendered apps, e.g. with Java, php, etc., with jQuery on the client side.
ChrisArchitect 3y ago
(2015)
- deleted 3y ago
  [deleted]
ed_blackburn 3y ago
I am six months into a startup. It's a Python monolith with Postgres. It's been a success. There's a product-market fit, paying customers, and a healthy roadmap. The team picked boring tech, and it was the right call. Now, we are scaling to add exponentially more customers and hiring more people. We need to add resilience. We must tackle challenges around back pressure, flaky third parties, etc. Now is the time to introduce additional complexities because they pay for themselves. Such complexities are introducing dedicated read models and caching so we compute on write instead of every query/request, some messaging tech. We want to use Node instead of Django for our client-facing Dashboards and Dynamo for some tables. In summary, the evolutionary journey of a system starting with a monolith, with a single language, and single db tech with some gnarly SQL isn't very sexy. Still, it takes you a long way before you must reevaluate and acknowledge that optimising for Flow and Pivoting over everything else turns into Flow and Cost to Serve. Your mileage may, of course, vary.
- cpursley 3y ago
  The problems you describe are what Elixir solves out of the box simply by being based on Erlang, including caching and pushing real-time data to dashboards. It’s also easy to learn coming from Python and Ruby.
- klabb3 3y ago
  > It's a Python monolith > flaky third parties Seems contradictory. What are the third parties used for?
  - ed_blackburn 3y ago
    I’m not referring to third party libraries. Rather third-party data providers.
KronisLV 3y ago
This is one of those pieces of advice that you don't need to get super specific about and can follow as loosely as fits your circumstances, but in general I think it's nice! I am doing a freelance thing and opted for mostly "boring" technology and so far it's working out great: * OCI containers (Ubuntu based) with Docker and Docker Swarm because it's simple/stable enough and has the features needed * Apache httpd as the web server of choice, because it has mod_auth_openidc integration to be an OpenID Connect Relying Party, less abstraction than a Kubernetes Ingress, too * .NET with ASP.NET and EF (Core) for the API, because the ecosystem is pretty coherent and it does most of what I need, yet still has an okay type system (much like Java) * Vue with various popular packages (Pinia, Vue Router, VueRequest/Axios, VueI18n, PrimeVue, PrimeFlex, PrimeIcons, ...) for the front end, because it's a good fit for the SPA and is simpler to use than React (IMO), yet doesn't have the complexity of Next/Nuxt; I actually considered Angular for the more batteries-included design, but Composition API is just great and most of those libraries are really easy to import and setup * MariaDB as the database of choice, because for simpler projects it's also easier to use MySQL/MariaDB than PostgreSQL: the model driven development tooling with MySQL Workbench is nice because of the codegen for migrations with dbmate later, as long as you don't need lots of complex in-database processing or transactional DDL, it just works * off the shelf software for day 2 concerns: Portainer for managing the cluster, Keycloak for user management, Matomo for analytics, Uptime Kuma for uptime monitoring, Apache Skywalking for APM and rsync for backups (for now); reasonably stable options for all of the code I don't want to write myself, especially in regards to auth/user management Will a blog post on what and how I built ever get lots of attention? Probably not. But is it good for shipping software? I'd argue that definitely! It lets me iterate reasonably quickly and also any learning I do is useful and not overwhelming due to its limited scope: e.g. adding VeeValidate instead of Vuelidate, configuring unplugin-vue-components, discovering VueUse, adding Capacitor into the mix, considering and subsequently discarding AutoMapper for EF/DTO, adding a plugin to my IDE to generate Entity mappings from a live database, working with spatial types in MariaDB (a bit less nice than PostGIS, but serviceable). All of this also scales far enough for the current resources at my disposal. At the point where the performance of Apache httpd wouldn't be enough, there'd probably be a bigger team that can migrate it to something else. Admittedly, sometimes this also means using SaaS for certain concerns, like using Mapbox for geocoding/routing, because self-hosting OpenMapTiles/OSRM/whatever would slow me down too much.
bl4ckm0r3 3y ago
I hate this, as usual all blanket statements are false assumptions. The presentation is mainly focused at new paradigms but technology is there to help us fix problems, and I totally agree that jumping on a cutting edge tech is very risky in most of the cases and can end up in wasting a lot of time finding workarounds on either limitations, bugs or immaturity of the chosen tech, BUT my problem with this is "where do you draw the line?". Is an on premise service boring tech? should we use that instead of aws? Is github actions too cutting edge? should we keep using jenkins for ci/cd? etc. It really depends on so many factors (like in house experience, really understanding the product and engineering needs, costs etc) and it does not take in consideration the "problems" of boring tech and why modern tech has tried to solve or avoid them. The last director who mentioned that to me and built everything in django and had huge scalability issues and took about 1 year and a half to refactor a part of the app to move away from context and orm. In my opinion the only thing that matters is "how coupled are you with the tech and how optimized for deletion and change is your code/infra"
- adamckay 3y ago
  > BUT my problem with this is "where do you draw the line?" Wherever it makes sense for you and your organisation. There's not a list of approved "boring technology" and unapproved "exciting but scary technology". It's not about the age of the technology, but your level of experience with it. If you know it inside out, understand its failure modes and can easily find information when something goes wrong it's "boring". If your team can configure AWS services in their sleep but have never touched a bare metal box then AWS is boring. On the flip side, if you're a bunch of Linux greybeards and wrote the book on iptables but can barely spell VPC then on-prem is boring. This is also where the concept of "innovation tokens" comes in. C++ is well established and quite far from innovative on its own, but if you're building a web app and your team is full of new graduates and interns that have only ever touched Javascript and Python then using C++ would spend one of your "innovation tokens" as your team is busy learning it instead of learning the business domain.
  - bl4ckm0r3 3y ago
    100% agreed, as I mentioned in house knowledge (and engineering size) matters when deciding this. In your example, if you only have recent graduates in your team you have a whole lot of different problems :D In a more common setup (some seniors, some juniors) given they will have to learn something on the road anyway, wouldn't you want to, for example, use managed services instead of "boring" services? Use svelte instead of angular? use flask instead of django? or fastify instead of express? And if you go boring because there's more literature on them, you will soon find out that most of it is confusing as it spans over the years (have you ever used springboot? so many different ways of doing things that evolved in time...) and in the beginning you'll end up using the - by the book- approach which does bring some complex problems (try refactoring the auth module out of an app). In the end what you are doing is moving the problem of figuring things out later in the future, when things are much more complex and refactoring is much more costly. But I agree with you in the end it depends on the org, which is why you should not choose boring tech by default, and not choose cool tech by default either and think more about what would really give you speed of execution and maintainability in an always changing business domain AND keep things small enough that can be refactored out in an as-easy-as-possible way. ps of course this is after like the first year of your startup, there's no point of doing any of this, or even choosing any technology if your company dies in 3 months. pps i still don't understand why early stage startups don't do everything in javascript (FE+BE) so the same engineers can contribute to both part of the stack and then decide what to change depending on the business needs
markcollin 3y ago
- choose the tech stack ur team is most comfortable with - focus on getting PPL to try your product, then revenue, then scale and then microservices - in that order
XCSme 3y ago
I randomly started building UXWizz[0] 13 years ago, on a (not completely sober) New Year's Eve, and choose the most boring stack ever: PHP, MySQL, jQuery. The platform has evolved so much over the years, but it's easier to maintain and install than day one, even if the codebase is 100x the size. I did do a refactoring in 2020[1], rewriting the entire front-end from spaghetti jQuery to TypeScript/React/MaterialUI, which you might argue is not the most boring stack, but simply "the norm" and a safe and easy and maintainable option. Now, three years later, I feel like I can make changes, add or remove any feature and create new ways to install the platform with ease (e.g. Docker? Simply add a COPY line in a Docker file using the LAMP stack to copy the PHP files; new UI element or page to display data from DB? Add a basic React component, a 5 lines PHP file with a MySQL SELECT query in it returning the data, and a fetch request). In 13 years I've seen analytics companies come and go, trends and stacks appear and disappear, and I think I've managed pretty well to keep up even with corporations with millions in founding while being myself a solo-founder and having worked on it mostly as a side project, I think this was the secret: keep the technology simple and focus on improving the current features as opposed to adding new ones. Also, be passionate about performance and simplicity: if you can make something both faster and simpler at the same time, do it now, it would save you so much time in the long run. This includes dev tooling too: like moving from webpack to parcel or vite (10s vs 1s build times, worth in the long run), or creating Gulp.JS tasks to automate manual process like uploading files, setting the file version in a readme file, and adding guards (if checks) like making sure you don't publish the dev version instead of the production one. Oh, and another secret: keep updating the libraries you are using: it's a lot easier to go from version v3 to v4 in 2019 and then v4 to v5 in 2021, then directly v3 to v5 in 2021. PS: Fun fact, when I started working on UXWizz (called userTrack before[3]), I started with the heatmaps and session recordings, it didn't have any stats/graphs for many years. Here's a screenshot of how it looked [4], [5]. [0]: https://uxwizz.com https://uxwizz.com [1]: https://docs.uxwizz.com/about/changelog#usertrack-3.0.0-beta-18-march-2020 https://docs.uxwizz.com/about/changelog#usertrack-3.0.0-beta... [3]: https://www.uxwizz.com/blog/rebrand-usertrack-is-now-uxwizz https://www.uxwizz.com/blog/rebrand-usertrack-is-now-uxwizz [4]: https://i.snipboard.io/B6xhu7.jpg https://i.snipboard.io/B6xhu7.jpg [5]: https://www.paldesk.com/wp-content/uploads/2020/04/userTrack-Wordpress-Plugin.png.jpg https://www.paldesk.com/wp-content/uploads/2020/04/userTrack...
jlouis 3y ago
One of the main points of this essay is that you have a certain budget for innovation, exemplified in a fixed token count, you spend on your tech stack. Once you are out of tokens, you end up injecting too much risk into the project, and it is likely to fail. I think this view has to be generalized. Your budget isn't simply affecting the tech of the system, but it also affects the whole: business case, decision loop, company maturity, etc. If the business case is a true moonshot vision of epic proportions, you have to think about what tech stack can support it. In some cases, you can be fairly conservative in your tech choices. That's probably a good idea if the business case is pretty wild and ambitious since it will ground the project nicely. However, in many cases things go hand in hand. There's often some important complex part of the business case which require complexity in the tech stack. Say, for the sake of the current spotlighted tech, the central component need a large language model. Then, that LLM is going to eat into your development effort budget quite a lot. You should probably focus on getting the core part of the system running quickly, and support it by conservative tools. The flip side is a quite straightforward business case. Then, the competitive edge needs to come from better application of the tech, and that will often require more innovative approaches. In summary: you need to think about where the innovation is in the project, and modify the tech choices accordingly.
sourcecodeplz 3y ago
PHP & MySQL FTW
AugustoCAS 3y ago
I do agree with a lot of the presentation. A word of caution though: some technologies that start by offering simplicity evolve over time to provide a very difficult to grok environment. So the evaluation about the cost of maintenance is not a do once and forget. And sometimes boring means roll your own. An important aspect of this for me is to pick the simplest solution: A bit of code > A library > A Framework > Platform, which I think is in line with the presentation.
cybrexalpha 3y ago
The important part is that "boring" is context dependant, entirely based on the team. Got a bunch of Kubernetes experts on your team? Then Kubernetes, for all it's complexity, is "boring".
K0SM0S 3y ago
Dan McKinley's innovation model is solid. If you're familiar with entrepreneurial literature (eg. HBR), or financial analytics, or even the prosumer DIY scene, you'll land on the same general principles. "Boring" is essentially a synonym for "reliable," a principle that holds true across sectors, especially in tech-adjacent fields. Nintendo's success is a case in point for the power of commoditizing reliable tech. Google's polyglot approach (Go, Kotlin, Dart…) might seem like an exception, but it's more likely a symptom of being "too big to notice friction." This will eventually manifest as either tech debt or a talent bottleneck. As for sectors that defy the "boring is best" mantra, they're rare. Even buzz-heavy areas like crypto and Web 3.0 often rely on tried-and-true languages like Java or Python. Domain-Specific Languages (DSLs) are the real game-changers, bridging monoliths to human-centric solutions. The only sector that genuinely benefits from "non-boring" tech is cutting-edge R&D—think languages like Julia.

195 points by signa11 3y ago

I've always hated this article and the "boring programmer" shtick. I've always found the "boring programmer" thing pretentiousness trying to disguise itself as humility.

ksec 3y ago

Previous Discussions. 367 Comments: https://news.ycombinator.com/item?id=26211721 https://news.ycombinator.com/item?id=26211721 84 Comments: https://news.ycombinator.com/item?id=31558887 https://news.ycombinator.com/item?id=31558887

dang 3y ago
Thanks! Macroexpanded: Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=31558887 https://news.ycombinator.com/item?id=31558887 - May 2022 (83 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=30389591 https://news.ycombinator.com/item?id=30389591 - Feb 2022 (13 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=26211721 https://news.ycombinator.com/item?id=26211721 - Feb 2021 (361 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=25322651 https://news.ycombinator.com/item?id=25322651 - Dec 2020 (204 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=23444594 https://news.ycombinator.com/item?id=23444594 - June 2020 (282 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246 - July 2019 (344 comments) Choose boring technology - https://news.ycombinator.com/item?id=16677583 https://news.ycombinator.com/item?id=16677583 - March 2018 (1 comment) Choose Boring Technology - https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215 - March 2015 (212 comments)
- ChrisArchitect 3y ago
  (2015) up top
  - dang 3y ago
    The linked page seemed to be a talk from 2018, not the essay from 2015, so I used that year. If that's wrong, we can correct.

claytonjy 3y ago

Is boring technology even an option in high-velocity fields like ML/AI? I can pick boring databases and boring servers but when it comes to model architectures, model weights, GPUs, serving frameworks, etc. there's been such massive improvements lately that it doesn't feel like anything has settled enough to be "boring". If I need a language model, or an image classifier, or an ASR model, there are older options which might be "boring", but they're not nearly as powerful as the latest options. Does choosing boring ML tech mean sitting out on massive recent advancements?

dgrin91 3y ago
99.999...% of us don't work or seriously touch in AI in any way. At best you make an API call to something that might do some AI, but at that point its just another service. So for the vast majority of people doing dev work, boring choices are correct. I've had a lot of junior devs come to me with proposals for microservice architectures that can autoscale, be orchestrated, have 0 downtime with red/blue deployments, etc, etc, when at the end of the day it could be done with a boring, single server (plus second for resiliency, but not needed for scaling) with just a few endpoints. It will be done much faster & simpler, which means it will be cheaper and less likely to fail. My guess is that the same is true in a lot of AI work. Yes there is core stuff that needs to be performant, scalable, and modern, but I'm sure there is also a ton of boring old regular internal corporate infra that can be done 'boring'.
- threeseed 3y ago
  The first approach will be significantly cheaper if using the cloud. It allows you to use spot/ephemeral instances and scale down capacity to almost zero cost without any loss in availability. Single server in the cloud is great for dev environments and if you don't care about uptime. But given that poor uptime is toxic for customer retention only incompetent businesses would deliberately not choose to use something better suited. Especially when it's so much cheaper.
  - lelanthran 3y ago
    > The first approach will be significantly cheaper if using the cloud. Only if you're regularly scaling down to zero (AKA too few paying customers to stay in business). > only incompetent businesses would deliberately not choose to use something better suited. There's a time and place for both approaches. If you're serving anywhere near the number of users needed to show a profit, spot instances are extremely expensive.

andrewstuart 3y ago

edit: Apparently "choose boring technology" is just clickbait, and in fact the guy advocates for all the nuanced technology selection advocated here.... so errr, apparently he in fact is saying "don't chose boring technology" or something, whatever. I completely disagree with almost any blanket philosophy on technology. Don't choose boring technology. Choose technology that suits the context: * choose what you like for personal projects * choose tech your team has the skills with * choose tech that won't be a problem to recruit people for (I'm looking at you, Ruby On Rails) * choose tech that gets the job done * choose tech that the industry is moving towards * choose tech that levels up your team's skills and makes them feel excited that they are learning and advancing * choose tech that allows you to meet the priorities of the project (your project does, define priorities, right. right?) security/availability/maintainability/performance/compatibility/whatever * choose tech that ensures your team and company won't be left behind when market skills move on * choose the cutting edge if you think that's the right choice for some reason It seems pointless to me to say "choose boring technology".

gfodor 3y ago
It turns out that it’s impossible to reasonably title any talk or article without it being considered a blanket statement. This is why you attach the talk or article to the hyperlink so people can continue understanding more of what you are saying.
- avindroth 3y ago
  Well, this is just clickbait. Choose boring technology means sth pretty concrete for someone without context. It’s not that you can’t reasonably title it. It’s that you can’t reasonably title it to generate views. I understand the sentiment, but then one should expect criticism of the schism between title and content.
  - gfodor 3y ago
    "Clickbait" has been apparently watered down to the point of meaninglessness then. You title things to get people to want to read them if you're sharing information you think is important. The term "clickbait" is typically used to refer to false and misleading titles to generate ad revenue for garbage content.

deleted 3y ago

[deleted]

Pannoniae 3y ago

While I see how this makes sense, I don't like this. If most people follow this strategy, we will end up with utter stagnation, or even devolution. "Boring" technology also has many hidden costs - most importantly, opportunity costs of not having several times higher productivity due to the warts and quirks of the boring tools. Sure, with enough practice one can work around them but every backwards issue takes a good chunk of productivity out of the project. I get the argument of "if it's not mainstream, where will we find programmers" - but that's more of a cultural issue of wanting expert programmers out of the box instead of investing in them and training them. Ultimately, this line of thinking is like saying 640K RAM is enough for everyone. Sure, you might say C++ and Go is enough for everyone, but there are many unrealised gains left on the table.

gfodor 3y ago
The talk doesn’t say to always choose boring technology. But you might think it does if you read three words and wrote a comment in response to them.
- Pannoniae 3y ago
  This was the second time I've read that talk. Please don't accuse me of not reading it. As all of us, it might be that I completely overlook, or interpret something entirely differently or outright wrongly, but I think this is entirely uncalled for. Edit: I kind of see what you mean now. My paragraph about hiring was somewhat tangential. I am sorry.
  - gfodor 3y ago
    No worries!
jpgvm 3y ago
That isn't how any of this works. We don't get new innovative databases because of small startups deciding they want to roll their own database as part of building their new fangdangled AI thing. We get new innovative database either by new innovative database companies that rightfully spend their time and effort trying a new idea in the space or out of huge companies with R&D budgets to build such things, like Spanner. Startups choosing boring tech for everything that isn't their core/critical innovative area should actually accelerate innovation by focussing effort more efficiently. I do agree that the whole hiring aspect of it is hot garbage though. If Haskell is the best fit for what you are making and is considering boring in your field (say you are doing verification) then it makes perfect sense to use it even if the pool is smaller because a) people that stick to Haskell despite its difficulties probably have more passion for the craft and b) it's way more likely someone that knows Haskell has some exposure to your field, verification in this case. Same can apply to lots of "niche" languages/tools/etc. Boring is relative to what you are working on. I build distributed systems primarily. For me boring is Java. I imagine C++ is boring for game devs/GPU folks. etc.

freelanceTA 3y ago

I want to choose tech that has the least amount of maintenance. For example I had to build a web app thing for something I'm doing. The many frameworks available are of course trivial to string together but now I'm looking at a huge amount of dependencies all that require a lot of maintenance. I went with avoiding all but the the most critical libraries for authentication but is there a better way? I found even writing in OCaml and generating js into a docker file to be hosted by someone else who maintains node.js was actually less maintenance than me using any existing frameworks

chadcmulligan 3y ago
I prefer jQuery and jQueryUI - actually I go one further and use the devextreme components so I have paid support (outrageous I know) for spa's or something like umbraco for CMS but they are very unsexy and old. Delphi for cross platform applications, but try and sell that as a development platform :-D I think the big advantage of this sort of stuff is you have a million debugged and working examples to pick from and people who know them inside out. Edit: I watch the kids trying to figure out how to release things on docker with their multiple git branches and merges, and re-engineering their microservices frameworks, and each time I die a bit inside. This was all done so long ago, why continue to make it harder. Now I'm not talking something google scale, but something with a few hundred users and maybe 20 concurrent, why would you do this, sigh.
- kyawzazaw 3y ago
  resume driven development
em-bee 3y ago
i found the key in reducing maintenance overhead is to avoid complex build tools that claim to manage your dependencies and use frameworks that don't frequently break compatibility.

mikece 3y ago

The points often lost here is that (1) this advice is aimed at startups, and (2) the whole concept of "innovation tokens." Any successful business is going to solve some problem which is probably not so obvious and that takes innovative thinking. If you're spending too much time trying to be innovative with your tech stack then you're NOT innovating on your specific difference as a business, and that hold you back (or could bankrupt you). All of that said, today's tech landscape is far less edgy than the early days of cloud, NoSQL, and NodeJS. I'm not even sure what tech is out there that would qualify as "spending your innovation tokens" other than AI.

eternityforest 3y ago
Blockchains, making your own JS framework/language/static site generator/MQTT alternative/etc, building a desktop GUI toolkit, making your own VCS, retro hipster type stuff like handwriting HTML with no templates or JS, or using Linux without some kind of configuration management system...
chii 3y ago
> I'm not even sure what tech is out there that would qualify as "spending your innovation tokens" other than AI. that's why they call it innovating. If you knew already, then it wouldn't be innovating, since it's not the innovation that's new.
jpgvm 3y ago
Biggest time wasters and innovation token consumers IMO is third-party vendors, especially shiny startups/products. Don't waste your time, money and energy being someone else's guinea pig, you need to be focused on your business problems. Bigger companies that have engineers and resources to waste can try these out for you and eventually that startup you knew a few years ago will either be successful and ready for you to use or dead and you will be glad you didn't waste the effort. Same goes for propropertary cloud services that have no business being proprietary. Biggest culprits here are data silo-ing lock-ins like DataDog, avoid like the plague. Use the standard off the shelf tools for everything you can, OSS may require slightly higher upfront integration costs in some cases, less than you think though, sometimes it's substantially faster due to integrations. Generally speaking if a project has been around long enough folks have already encountered every problem and shared every solution. If you are stuck with some proprietary vendor for some important part of your stack and you are hitting an edge condition you had better hope you are a big enough fish for them to care (hint: You aren't). I guess at the end of the day keep yourself off the Kool-Aid, ignore marketing speak and always ask hard questions of things and you will avoid innovation token sinks.

lmm 3y ago

He writes all this philosophy and then concludes with using PostgreSQL instead of mongoDB or nodeJS (? I'm not sure how that was in the same category). PostgreSQL is the opposite of boring technology; I've been using it for over 10 years and am still discovering new and surprising features with new and surprising failure modes; PostgreSQL today is very different from PostgreSQL 10 years ago, but setting it up for true master-master replication is still a clusterfuck and you still have zillions of moving parts in real world use. I'm lead inevitably to the conclusion that philosophising about tech choices and principles is pointless. Everyone will nod and agree with the principles and tradeoffs and then pick their personal pet technology anyway.

gaganyaan 3y ago
You're kind of missing the point, unless you're saying that regular PostgreSQL also has interesting failure modes. PostgreSQL clustering may not be boring technology, but that just means you scale up instead of out. If you run out of headroom for scaling up, that probably means you're successful enough that you can take a look at non-boring technology.
kyawzazaw 3y ago
doesn't that mean you are now ready for a new innovation token, which is inline with the written philosophy?
ksec 3y ago
I would have thought MySQL would be a better fit for boring technology.
- gaganyaan 3y ago
  Given that the author compared MongoDB vs PostgreSQL, I think the technology in question is SQL vs NoSQL, not a particular flavor of SQL vs the other.
simonw 3y ago
PostgreSQL is absolutely boring technology. What makes it boring is: - people have been using it for decades, for all kinds of different things - this means that any problem you run into, someone else will have seen before - and will have talked about it online - you're not going to be using it to solve a class of problems that no one else has used it for before

LAC-Tech 3y ago

I feel like this has been misunderstood for years. I note this paragraph: But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down. I understand F# more than I understand PHP. By the articles definition, F# is 'boring', and choosing to do something in PHP would be using up an innovation token.

hooverd 3y ago
If it works you and/or your org, then yeah.
joshuahutt 3y ago
Another thing to keep in mind is the size of the candidate pool. There's a lot fewer F# devs than PHP. Can make hiring a bit trickier.
- worthless-trash 3y ago
  And I was under the impression that coders were thought of as replaceable cogs in a machine, one just as good as the next.
- jpgvm 3y ago
  This is almost never a bad thing. It means you have fewer people to compete with when advertising a position and the people that use a niche technology generally have more passion for their craft.
  - dukeyukey 3y ago
    Although it also delays hiring - I work for a startup using Kotlin, and we've had maybe three candidates _ever_ who have used Kotlin beyond hobby projects. And I was one of them!
- photonbeam 3y ago
  You might get less volume, but you can use this as an advantage

fnfjfk 3y ago

This article gets posted a lot, but I find it a little unsatisfying. I think it’s because it’s pretty vague about what “boring” means exactly, so it’s the kind of statement most can agree with, without it actually being a very strong statement. It’s not wrong per se, don’t choose some technology posted for the first time yesterday. But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea. The specific languages it calls out are Python and PHP, which IMO are bug-prone languages with serious performance/efficiency implications. Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet). I would say more important is “write boring code”, and it is easier to write boring to-the-point code in modern languages without implicit null references, with sum types for modeling mutually-exclusive data, and with as many other common pitfalls statically eliminated as is possible.

kyawzazaw 3y ago
> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea. But isn't the point that if you run into this much issue for the initial choice, you are now ready to use an innovation token and switch to a different one? > Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet). At that point with all the financial resources, they can consider to rewrite/migrate. Thus, at the start, chose boring technology. Even at a big company, retraining or hiring people proficient in Rust will probably cost more than continuing to use C++ codebase and people.
- hgomersall 3y ago
  Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. We dropped C for Rust in a systems language context and technologically it was a fantastic choice. I guess some of the benefits of a language switch could have been realised with C++, but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Rust held far more appeal and in hindsight has helped us provided fantastic stability in our software whilst developing very rapidly.

tuyiown 3y ago

Looks like a very convoluted way to say that you should avoid mistakes, but with confusion between familiarity and in depth analysis. Worst surprises generally comes from non verified expectations, and ends up to hard to workaround problems that becomes clear in hindsight «It never really worked that way». You have better chances to avoid that with tech you are familiar with, but the only real way is to verify how the thing is built, and on what principles, confront that to your knowledge, and if it aligns you have greatly improved the chances of things going smoothly. Since people are generally not rational and rarely do those checks, when working with a team, going with familiarity is the safe route.

MichaelMoser123 3y ago

and who defines what is boring?

worthless-trash 3y ago
This is the big question.
em-bee 3y ago
boring is what you already know and don't need to spend a lot of time learning, or, if you don't know any, then it's what is widely known and well documented.
- MichaelMoser123 3y ago
  Already know? I think that any technologies can pose a non boring challenges. These tend to happen when a technology is used at scale, or with an unusual use cases. Look at 'boring' php, facebook was using this language at scale, so they had to develop a just in time compiler for the whole thing. Python didn't have that problem, so it still doesn't have a just in time compiler (for the default interpreter) Also look at all the changes and action in the JDK (ever since JDK11). Is that also boring?
  - em-bee 3y ago
    I think that any technologies can pose a non boring challenges. These tend to happen when a technology is used at scale, or with an unusual use cases. yes, that is true but i think that supports the point: use boring tech to solve interesting problems.
    - MichaelMoser123 3y ago
      i think it that the definition of 'proven' technology smells of silos: if you come from the Java world, then everything else is not relevant, same for php/python, same for the nodejs world.

TurboHaskal 3y ago

I mean I would love writing Ada and Common Lisp at work but my hipster CTO wants me to use Go and TypeScript.

philippta 3y ago

What is the boring technology for frontend development?

LAC-Tech 3y ago
The one you know the best.
somesortofthing 3y ago
Though it was far less clear when this article was written than it is now, if you're starting from scratch on a webapp today it's hard to go wrong with React.
- em-bee 3y ago
  there are a lot of voices against react too, so i would be careful. react is a good choice in that its downsides are well known and documented, so at least you can make an informed choice. but i would cast a wider net and look at svelte, vue and angular as well. personally i use aurelia, but it being less popular means that less people write about it so there may be hidden downsides. i am already familiar with it which is sufficient to qualify as boring for me. and i am also solving boring problems which allows me to spend my innovation tokens on my tech stack.
petepete 3y ago
HTML and CSS. Boring, reliable, accessible, extendable. Only reach for JavaScript when it's actually required - which is less often than the modern web would suggest.
- shepherdjerred 3y ago
  This is not at all what the article is advocating for.
shepherdjerred 3y ago
React and Vue probably qualify as a boring tech, but you could also use traditional server-rendered apps, e.g. with Java, php, etc., with jQuery on the client side.

ChrisArchitect 3y ago

(2015)

deleted 3y ago
[deleted]

ed_blackburn 3y ago

I am six months into a startup. It's a Python monolith with Postgres. It's been a success. There's a product-market fit, paying customers, and a healthy roadmap. The team picked boring tech, and it was the right call. Now, we are scaling to add exponentially more customers and hiring more people. We need to add resilience. We must tackle challenges around back pressure, flaky third parties, etc. Now is the time to introduce additional complexities because they pay for themselves. Such complexities are introducing dedicated read models and caching so we compute on write instead of every query/request, some messaging tech. We want to use Node instead of Django for our client-facing Dashboards and Dynamo for some tables. In summary, the evolutionary journey of a system starting with a monolith, with a single language, and single db tech with some gnarly SQL isn't very sexy. Still, it takes you a long way before you must reevaluate and acknowledge that optimising for Flow and Pivoting over everything else turns into Flow and Cost to Serve. Your mileage may, of course, vary.

cpursley 3y ago
The problems you describe are what Elixir solves out of the box simply by being based on Erlang, including caching and pushing real-time data to dashboards. It’s also easy to learn coming from Python and Ruby.
klabb3 3y ago
> It's a Python monolith > flaky third parties Seems contradictory. What are the third parties used for?
- ed_blackburn 3y ago
  I’m not referring to third party libraries. Rather third-party data providers.

KronisLV 3y ago

This is one of those pieces of advice that you don't need to get super specific about and can follow as loosely as fits your circumstances, but in general I think it's nice! I am doing a freelance thing and opted for mostly "boring" technology and so far it's working out great: * OCI containers (Ubuntu based) with Docker and Docker Swarm because it's simple/stable enough and has the features needed * Apache httpd as the web server of choice, because it has mod_auth_openidc integration to be an OpenID Connect Relying Party, less abstraction than a Kubernetes Ingress, too * .NET with ASP.NET and EF (Core) for the API, because the ecosystem is pretty coherent and it does most of what I need, yet still has an okay type system (much like Java) * Vue with various popular packages (Pinia, Vue Router, VueRequest/Axios, VueI18n, PrimeVue, PrimeFlex, PrimeIcons, ...) for the front end, because it's a good fit for the SPA and is simpler to use than React (IMO), yet doesn't have the complexity of Next/Nuxt; I actually considered Angular for the more batteries-included design, but Composition API is just great and most of those libraries are really easy to import and setup * MariaDB as the database of choice, because for simpler projects it's also easier to use MySQL/MariaDB than PostgreSQL: the model driven development tooling with MySQL Workbench is nice because of the codegen for migrations with dbmate later, as long as you don't need lots of complex in-database processing or transactional DDL, it just works * off the shelf software for day 2 concerns: Portainer for managing the cluster, Keycloak for user management, Matomo for analytics, Uptime Kuma for uptime monitoring, Apache Skywalking for APM and rsync for backups (for now); reasonably stable options for all of the code I don't want to write myself, especially in regards to auth/user management Will a blog post on what and how I built ever get lots of attention? Probably not. But is it good for shipping software? I'd argue that definitely! It lets me iterate reasonably quickly and also any learning I do is useful and not overwhelming due to its limited scope: e.g. adding VeeValidate instead of Vuelidate, configuring unplugin-vue-components, discovering VueUse, adding Capacitor into the mix, considering and subsequently discarding AutoMapper for EF/DTO, adding a plugin to my IDE to generate Entity mappings from a live database, working with spatial types in MariaDB (a bit less nice than PostGIS, but serviceable). All of this also scales far enough for the current resources at my disposal. At the point where the performance of Apache httpd wouldn't be enough, there'd probably be a bigger team that can migrate it to something else. Admittedly, sometimes this also means using SaaS for certain concerns, like using Mapbox for geocoding/routing, because self-hosting OpenMapTiles/OSRM/whatever would slow me down too much.

bl4ckm0r3 3y ago

I hate this, as usual all blanket statements are false assumptions. The presentation is mainly focused at new paradigms but technology is there to help us fix problems, and I totally agree that jumping on a cutting edge tech is very risky in most of the cases and can end up in wasting a lot of time finding workarounds on either limitations, bugs or immaturity of the chosen tech, BUT my problem with this is "where do you draw the line?". Is an on premise service boring tech? should we use that instead of aws? Is github actions too cutting edge? should we keep using jenkins for ci/cd? etc. It really depends on so many factors (like in house experience, really understanding the product and engineering needs, costs etc) and it does not take in consideration the "problems" of boring tech and why modern tech has tried to solve or avoid them. The last director who mentioned that to me and built everything in django and had huge scalability issues and took about 1 year and a half to refactor a part of the app to move away from context and orm. In my opinion the only thing that matters is "how coupled are you with the tech and how optimized for deletion and change is your code/infra"

adamckay 3y ago
> BUT my problem with this is "where do you draw the line?" Wherever it makes sense for you and your organisation. There's not a list of approved "boring technology" and unapproved "exciting but scary technology". It's not about the age of the technology, but your level of experience with it. If you know it inside out, understand its failure modes and can easily find information when something goes wrong it's "boring". If your team can configure AWS services in their sleep but have never touched a bare metal box then AWS is boring. On the flip side, if you're a bunch of Linux greybeards and wrote the book on iptables but can barely spell VPC then on-prem is boring. This is also where the concept of "innovation tokens" comes in. C++ is well established and quite far from innovative on its own, but if you're building a web app and your team is full of new graduates and interns that have only ever touched Javascript and Python then using C++ would spend one of your "innovation tokens" as your team is busy learning it instead of learning the business domain.
- bl4ckm0r3 3y ago
  100% agreed, as I mentioned in house knowledge (and engineering size) matters when deciding this. In your example, if you only have recent graduates in your team you have a whole lot of different problems :D In a more common setup (some seniors, some juniors) given they will have to learn something on the road anyway, wouldn't you want to, for example, use managed services instead of "boring" services? Use svelte instead of angular? use flask instead of django? or fastify instead of express? And if you go boring because there's more literature on them, you will soon find out that most of it is confusing as it spans over the years (have you ever used springboot? so many different ways of doing things that evolved in time...) and in the beginning you'll end up using the - by the book- approach which does bring some complex problems (try refactoring the auth module out of an app). In the end what you are doing is moving the problem of figuring things out later in the future, when things are much more complex and refactoring is much more costly. But I agree with you in the end it depends on the org, which is why you should not choose boring tech by default, and not choose cool tech by default either and think more about what would really give you speed of execution and maintainability in an always changing business domain AND keep things small enough that can be refactored out in an as-easy-as-possible way. ps of course this is after like the first year of your startup, there's no point of doing any of this, or even choosing any technology if your company dies in 3 months. pps i still don't understand why early stage startups don't do everything in javascript (FE+BE) so the same engineers can contribute to both part of the stack and then decide what to change depending on the business needs

markcollin 3y ago

- choose the tech stack ur team is most comfortable with - focus on getting PPL to try your product, then revenue, then scale and then microservices - in that order

XCSme 3y ago

I randomly started building UXWizz[0] 13 years ago, on a (not completely sober) New Year's Eve, and choose the most boring stack ever: PHP, MySQL, jQuery. The platform has evolved so much over the years, but it's easier to maintain and install than day one, even if the codebase is 100x the size. I did do a refactoring in 2020[1], rewriting the entire front-end from spaghetti jQuery to TypeScript/React/MaterialUI, which you might argue is not the most boring stack, but simply "the norm" and a safe and easy and maintainable option. Now, three years later, I feel like I can make changes, add or remove any feature and create new ways to install the platform with ease (e.g. Docker? Simply add a COPY line in a Docker file using the LAMP stack to copy the PHP files; new UI element or page to display data from DB? Add a basic React component, a 5 lines PHP file with a MySQL SELECT query in it returning the data, and a fetch request). In 13 years I've seen analytics companies come and go, trends and stacks appear and disappear, and I think I've managed pretty well to keep up even with corporations with millions in founding while being myself a solo-founder and having worked on it mostly as a side project, I think this was the secret: keep the technology simple and focus on improving the current features as opposed to adding new ones. Also, be passionate about performance and simplicity: if you can make something both faster and simpler at the same time, do it now, it would save you so much time in the long run. This includes dev tooling too: like moving from webpack to parcel or vite (10s vs 1s build times, worth in the long run), or creating Gulp.JS tasks to automate manual process like uploading files, setting the file version in a readme file, and adding guards (if checks) like making sure you don't publish the dev version instead of the production one. Oh, and another secret: keep updating the libraries you are using: it's a lot easier to go from version v3 to v4 in 2019 and then v4 to v5 in 2021, then directly v3 to v5 in 2021. PS: Fun fact, when I started working on UXWizz (called userTrack before[3]), I started with the heatmaps and session recordings, it didn't have any stats/graphs for many years. Here's a screenshot of how it looked [4], [5]. [0]: https://uxwizz.com https://uxwizz.com [1]: https://docs.uxwizz.com/about/changelog#usertrack-3.0.0-beta-18-march-2020 https://docs.uxwizz.com/about/changelog#usertrack-3.0.0-beta... [3]: https://www.uxwizz.com/blog/rebrand-usertrack-is-now-uxwizz https://www.uxwizz.com/blog/rebrand-usertrack-is-now-uxwizz [4]: https://i.snipboard.io/B6xhu7.jpg https://i.snipboard.io/B6xhu7.jpg [5]: https://www.paldesk.com/wp-content/uploads/2020/04/userTrack-Wordpress-Plugin.png.jpg https://www.paldesk.com/wp-content/uploads/2020/04/userTrack...

jlouis 3y ago

One of the main points of this essay is that you have a certain budget for innovation, exemplified in a fixed token count, you spend on your tech stack. Once you are out of tokens, you end up injecting too much risk into the project, and it is likely to fail. I think this view has to be generalized. Your budget isn't simply affecting the tech of the system, but it also affects the whole: business case, decision loop, company maturity, etc. If the business case is a true moonshot vision of epic proportions, you have to think about what tech stack can support it. In some cases, you can be fairly conservative in your tech choices. That's probably a good idea if the business case is pretty wild and ambitious since it will ground the project nicely. However, in many cases things go hand in hand. There's often some important complex part of the business case which require complexity in the tech stack. Say, for the sake of the current spotlighted tech, the central component need a large language model. Then, that LLM is going to eat into your development effort budget quite a lot. You should probably focus on getting the core part of the system running quickly, and support it by conservative tools. The flip side is a quite straightforward business case. Then, the competitive edge needs to come from better application of the tech, and that will often require more innovative approaches. In summary: you need to think about where the innovation is in the project, and modify the tech choices accordingly.

sourcecodeplz 3y ago

PHP & MySQL FTW

AugustoCAS 3y ago

I do agree with a lot of the presentation. A word of caution though: some technologies that start by offering simplicity evolve over time to provide a very difficult to grok environment. So the evaluation about the cost of maintenance is not a do once and forget. And sometimes boring means roll your own. An important aspect of this for me is to pick the simplest solution: A bit of code > A library > A Framework > Platform, which I think is in line with the presentation.

cybrexalpha 3y ago

The important part is that "boring" is context dependant, entirely based on the team. Got a bunch of Kubernetes experts on your team? Then Kubernetes, for all it's complexity, is "boring".

K0SM0S 3y ago

Dan McKinley's innovation model is solid. If you're familiar with entrepreneurial literature (eg. HBR), or financial analytics, or even the prosumer DIY scene, you'll land on the same general principles. "Boring" is essentially a synonym for "reliable," a principle that holds true across sectors, especially in tech-adjacent fields. Nintendo's success is a case in point for the power of commoditizing reliable tech. Google's polyglot approach (Go, Kotlin, Dart…) might seem like an exception, but it's more likely a symptom of being "too big to notice friction." This will eventually manifest as either tech debt or a talent bottleneck. As for sectors that defy the "boring is best" mantra, they're rare. Even buzz-heavy areas like crypto and Web 3.0 often rely on tried-and-true languages like Java or Python. Domain-Specific Languages (DSLs) are the real game-changers, bridging monoliths to human-centric solutions. The only sector that genuinely benefits from "non-boring" tech is cutting-edge R&D—think languages like Julia.