[bl4ckm0r3]

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]

> 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]

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