[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