Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's not microservice or monolith; it's cognitive load

fernandovillalba.substack.com

Post reply on HN
Print view View original

21–30 of 195 posts

Re: It's not microservice or monolith; it's cognitive load

#21

Post by dboreham »

hmeh wrote: post #17
hmeh wrote: post #14

It’s hard to imagine worse advice. Software design principles lead you to good architecture. Focus on autonomy, proper partitioning, and sound design and you get what you get. If you target monoliths out of some misguided attempt to reduce cognitive load, you will only create unnecessary entanglement. If you try to target “microservices” with N services per team or other arbitrary target, you will end up missing boun…

Just read the author’s bio. This is a person that appears to have zero software design experience writing an article telling you to ignore software design and just respect your team configuration. I call this Conway’s Confusion.

The entire purpose of microservices is to comply with Conway.

Re: It's not microservice or monolith; it's cognitive load

#22

Post by hmeh »

dboreham wrote: post #21
hmeh wrote: post #17

Earlier quoted context omitted.

Just read the author’s bio. This is a person that appears to have zero software design experience writing an article telling you to ignore software design and just respect your team configuration. I call this Conway’s Confusion.

The entire purpose of microservices is to comply with Conway.

This is wrong. That's not how Conway's Law works. It’s also not how software design works. But please, by all means, continue to spread disinformation and keep us in the dark ages.

Re: It's not microservice or monolith; it's cognitive load

#23

Post by jahewson »

ldjkfkdsjnv wrote: post #15

I used to complain about overly complex software, until I realized the problems themselves were very complex. There was/is no way around complexity, and pushing for early simplicity causes more problems than it solves. People need to accept that encoding 1,000 if else statements (software engineering) will be complex no matter how you spin it. Just design the software upfront for what you will need, like a profession…

> Just design the software upfront

We call that waterfall :)

Re: It's not microservice or monolith; it's cognitive load

#25

Post by malfist »

ldjkfkdsjnv wrote: post #15

I used to complain about overly complex software, until I realized the problems themselves were very complex. There was/is no way around complexity, and pushing for early simplicity causes more problems than it solves. People need to accept that encoding 1,000 if else statements (software engineering) will be complex no matter how you spin it. Just design the software upfront for what you will need, like a profession…

There's a balance to strike, right? Some complexity is just for complexity's sake, or out of inexperience or incompetence. But yeah, a lot of it is that the real world is complicated. That's convoluted code is solving for a bug an engineer was woken up at night for.

And it can be really hard to tell the difference

Re: It's not microservice or monolith; it's cognitive load

#26

Post by nateburke »

The moment you adopt service based teams with service based managers, say goodbye to engineers caring about working product. Say hello to cross team meetings and project management every time you want to ship a feature.

It's pure vanity for a startup to think they will become the next AWS by adopting hard service-based contracts between teams.

Re: It's not microservice or monolith; it's cognitive load

#27

Post by hmeh »

dboreham wrote: post #21
hmeh wrote: post #17

Earlier quoted context omitted.

Just read the author’s bio. This is a person that appears to have zero software design experience writing an article telling you to ignore software design and just respect your team configuration. I call this Conway’s Confusion.

The entire purpose of microservices is to comply with Conway.

Source: I lead a team of a dozen or so and we have over 100 deployed components. We don’t call them microservices, because we aren’t web developers pretending to do architecture and recreating the mistakes of DCOM, CORBA, and Web Services. Most of them are autonomous event sourced components. The others are stand alone web applications that are stitched together with Nginx routing and SSI. The user has no idea they are interacting with 100 apps, but the devs sure do.

Re: It's not microservice or monolith; it's cognitive load

#28

Post by hmeh »

jahewson wrote: post #23
ldjkfkdsjnv wrote: post #15

I used to complain about overly complex software, until I realized the problems themselves were very complex. There was/is no way around complexity, and pushing for early simplicity causes more problems than it solves. People need to accept that encoding 1,000 if else statements (software engineering) will be complex no matter how you spin it. Just design the software upfront for what you will need, like a profession…

> Just design the software upfront We call that waterfall :)

No, we don’t.

Re: It's not microservice or monolith; it's cognitive load

#29

Post by teaearlgraycold »

ldjkfkdsjnv wrote: post #20
imachine1980_ wrote: post #18

Earlier quoted context omitted.

i work in legacy code over abstraction gives more headaches than having to check manually when you need to change the software and the person who write it isn't in the company in the last five years, because the software is full of constrains that you don't known, and when you need to change something basic the whole software collapse(because of the interdependence of the componentes).

Right but thats just bad programming. If they had used no abstraction it would also be a nightmare.

Rememeber: Having no abstraction is better than the wrong abstraction.

Re: It's not microservice or monolith; it's cognitive load

#30

Post by ddejohn »

nateburke wrote: post #26

The moment you adopt service based teams with service based managers, say goodbye to engineers caring about working product. Say hello to cross team meetings and project management every time you want to ship a feature. It's pure vanity for a startup to think they will become the next AWS by adopting hard service-based contracts between teams.

This strikes me as overly cynical.

My current job is working with around 20 other engineers on an extremely bloated and coupled monolith. I'd love to be able to separate myself and my team from others by an agreed-upon interface.

Yes, "agreed-upon" is certainly doing some heavy lifting there, but I don't think it's realistic to expect that

> cross team meetings and project management every time you want to ship a feature

is somehow avoidable in tech?

Post reply on HN