[Aeolun]

I never really understood how insane it can get until my current job. We literally have a system diagram with like 30-40 different components (proxies, lambdas, pretty much all aws services), for a system that would work just as well with 3 (front/back/database).

At this point it’s become a kind of joke for me because anything else would be too depressing.

[sergiotapia]

Search for baklava code. Or architecture astronauts.

It's comes from leadership and trickles down to individual engineers. If your leader is deep into this mindset of completely over engineering things, you are screwed. I quit a job like this because the system was just too much. It was making me hate my profession and that's when I knew it was time to go.

You can get so far with a simple monolith, there is no need to suffer the whims of someone justifying their position.

[krzepah]

Hi,

I've had the luck to work on a 10 years old Django System. Everyone from the 6 people working on it said it was the purest sh.t they saw.

On the other hand, I need to learn new stuff. I tried Express or other JS fmw but these are not new things.

You can get pretty sh.tty unusable code with a monolith, while state-of-the-art is expected to be understood and seek by people that crave for more.

Tbh, I think it all depends on how well a team is prepared, and ofc it is more complex with the later tools, but they definitely avoid a lot of useless and shame code.

It is also very common that business hasn't validated their initial client base.

[NicoJuicy]

It's called over engineering or premature optimalisation.

It's insane how many companies scale for growth that they will never achieve. Even if they are successfull.

It's not that you can, that you should do it is my living mantra.