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

31–40 of 195 posts

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

#31

Post by lenerdenator »

aikiplayer wrote: post #11
amw-zero wrote: post #7

We can’t measure cognitive load though. Or if we can, no one knows a way to apply that to software projects.

We might not be able to quantitatively measure it but we can run studies to evaluate what individuals and teams can handle. Human factors people do this and it’s a sub field in industrial engineering. The military runs these studies and I’d imagine air traffic controllers do them as well, etc. You sometimes get really surprising results.

That's something I've noticed: the way we treat systems developed to work on data is _completely_ different from systems developed to work on, idk, oil.

You can build data refineries (ETF) same as an oil refinery. The difference is, the engineers who build the oil refinery create manuals and standard operating procedures to operate the refinery, because if they don't, then the new board operator will press the wrong button and blow out every window in a five-mile radius.

When you build a data refinery, no one documents _anything_ no matter how many times you ask engineers on the team to do it. Will it blow up in a massive fireball if you do it wrong? No, but it will corrupt data and have a business consequence. You can keep the 40 different microservices for the data refinery in your head though, right?

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

#32

Post by guhcampos »

mariodiana wrote: post #24

“[D]esign the software to fit the maximum team cognitive load.” I see. So, RAID drives, failover servers for redundancy, and generators (or at least UPS batteries) for power — but push your team to their maximum load.

Might be a bit of a wording thing, because I think I got it very differently than you.

To me, that sounds like "you can't design for a higher cognitive load than what your team can absorb" - and not "try to optimize the cognitive load dor the maximum your team can absorb".

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

#33

Post by ldjkfkdsjnv »

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 its called software engineering

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

#34

Post by ldjkfkdsjnv »

malfist wrote: post #25
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

People just get burned by bad programmers. So they make up all these rules to safe guard against them. Its not abstraction thats the problem, its low quality engineers.

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

#35

Post by guhcampos »

hmeh wrote: post #22
dboreham wrote: post #21

Earlier quoted context omitted.

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.

I don't disagree completely with the comment, but I would possibly change it from "comply with Conway" tô "embrace Conway".

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

#36

Post by pdonis »

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 for what you will need

That assumes that you know upfront what you will need and what software design will best meet the need. Sometimes that is the case, but many times it isn't. Different strategies are needed to deal with the latter case.

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

#38

Post by irjustin »

ddejohn wrote: post #30
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 fea…

> 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

This is overly cynical to you likely because you haven't experienced maintaining micro-services in the long term. Being able to "break away" with a common interface is literally the microservice tag line. It's completely true too. Standing up a service w/ an interface is incredibly fast, rewarding and watching it hum is beautiful.

The problem starts when there's a bug that's upstream of your service. It's not too hard to get all 15+ services running on your laptop, but the problem is the other teams no longer let external members directly deploy the services they maintain (that one time someone from another team deployed a big bug). So now you've got to get PR approval and seemingly no one wants to review your bug. So you ask for time from the Product Owner and it gets forgotten because they're really busy too. So you go to an eng manager, etc etc...

The above scenario plays out SO many times. I've been there in all various forms. As a blunt statement - any team under 30 members, monolith.

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

#39

Post by alexalx666 »

3cats-in-a-coat wrote: post #10

The sad thing about these "monolith vs microservice" debates is that to this day we have programming languages which favor shared mutable state, so a program written like this is an absolute hell (or a very leaky abstraction) to distribute. And it doesn't have to be like this. Think about it. When your variable is a simple value, like a number or a string or a struct, we treat it as pass-by-copy (even if copy-on-writ…

The tradeoffs are great if you are mindful

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

#40

Post by slabity »

guhcampos wrote: post #32
mariodiana wrote: post #24

“[D]esign the software to fit the maximum team cognitive load.” I see. So, RAID drives, failover servers for redundancy, and generators (or at least UPS batteries) for power — but push your team to their maximum load.

Might be a bit of a wording thing, because I think I got it very differently than you. To me, that sounds like "you can't design for a higher cognitive load than what your team can absorb" - and not "try to optimize the cognitive load dor the maximum your team can absorb".

It sounds like it should have been worded like, "Minimize cognitive load to maximize team effectiveness"

The original wording sounds like could go both ways, so I understand why the person you're responding to sees it that way.

Post reply on HN