[nodejs_rulez_1]

Only works for small projects, doesn't scale in terms of maintenance.

Same sort of issue makes people use microservices not because of their true advantages but simply to enforce boundaries between features because so many people lack discipline to make a well-structured (distributed) monolith.

[endisneigh]

Without knowing the problem it’s hard to say if they were right or wrong to do that.

[nodejs_rulez_1]

I just know that "divide and conquer" works and impure functions with side effects don't.

[Raidion]

I mean, your statement assumes a definition for "work". Reusability and maintainability are features, and for certain scopes, they may be overkill. I think this is where the really good software developers shine: You have to know the rules before you break them for sure, but pretending there isn't opportunity costs in software development is a big problem. Shipping anything gets you feedback, and that feedback can drastically change what you decide to build.

This is coupled with organizational dynamics where to get resources you have to prove value. Proving value is a lot harder than scaling/rewriting a software system, because if you need to scale a software system, you have rewards and money attached which are good business drivers. If you need to prove business value, no one cares (and you won't get resources) until you do.

It's a fine line to walk for sure.

[nodejs_rulez_1]

I am a developer not a manager, getting resources is not my problem but maintaining bad code is. In the end of the day business does not understand technical debt, so it's my duty to manage it transparently and well in advance. Perhaps start-ups that need to capture market or something are a different story.