this post was submitted on 12 May 2024
617 points (92.2% liked)

Programmer Humor

19512 readers
428 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 40 points 6 months ago (2 children)

The problem is that all projects start small, and frankly most of them die small. Aiming for microservices architecture right away is a surefire way to get the project killed before anyone would benefit off of the microservices.

[–] [email protected] 48 points 6 months ago (1 children)

The other angle is the majority of Devs are just... Not good...

A good Dev in the situation you mention will design the solution needed now not the one you hope for later.

I'm saying this as someone who has been mired in scope creep and over engineering solutions many times in my life because "what if 5000 people need to use it at once?!"

In most cases all you need is a database, a single thread and a simple API. Build it and then as the problems come grow with them. Try to take into account issues of scale but realize you can't and shouldn't solve every scenario because there are too many variables which may never exist.

[–] [email protected] 29 points 6 months ago (3 children)

A good Dev in the situation you mention will design the solution needed now not the one you hope for later.

Maintainability is one of the most important if not the most important goal when programming. If a dev only designs a solution that fits for exactly the current situation but doesn't allow any changes, it's not a good dev.
But yeah, if you start small, a solution that's made for that is preferable. You can still refactor things when you get magnitudes larger and have the budget.

[–] [email protected] 21 points 6 months ago* (last edited 6 months ago) (1 children)

The tricky thing about software development is this balance: you don't want to hobble your system by designing only for today, because that could waste a whole lot of time later when needs change, but you also mustn't paralyze the project by designing for all possible tomorrows. Finding a middle path is the art, and the only proof that you got it somewhat right is that things get done with relatively few crises.

[–] [email protected] 6 points 6 months ago

Microservice from the start may be a lot of overhead, but it should at least be made with that scalability in mind. In practice to me, that just means simple things like make sure you can configure it via environment vars, run it out of docker compose or something because you need to be able install it on all your dev systems and your prod server. That basic setup will let you scale if/when you need to, and doesn't add anything extra when planned from the start.

Allocating infrastructure on a cloud service with auto scaling is the hard part imo. But making the app support the environment from the start isn't as hard.

[–] [email protected] 19 points 6 months ago

Often a simple solution is the most maintainable solution. In my experience, the code that’s most difficult to maintain are often made by devs who tried to plan ahead. The code turns over engineered to allow for stuff that never materialized.

[–] [email protected] 5 points 6 months ago* (last edited 6 months ago) (1 children)

If a dev only designs a solution that fits for exactly the current situation but doesn't allow any changes, it's not a good dev.

I don't think anybody is arguing this. Nobody (in my decade-plus in this industry) actively codes in a way to not allow any changes.

[–] [email protected] 4 points 6 months ago

You evidently haven't met my colleagues. There are always people who go for the quickest hack despite the trouble it stores up for later, and they're usually encouraged by management.

[–] [email protected] 20 points 6 months ago (1 children)

I always lump microservices architecture as premature optimization, one that should be used when you're maxed out of resources or everything is too spaghetti.

I love the idea. And I even pitched it for a specific project. But I had to eat humble pie when the devops nerds threw more servers at the problem and it worked better than I expected.

[–] [email protected] 4 points 6 months ago

Sounds like that thing was already designed to be horizontally scalable. Was your error related to not realizing that? Or what was the problem being solved by microservices?