←back to thread

1087 points smartmic | 6 comments | | HN request time: 0.825s | source | bottom
Show context
anthomtb ◴[] No.44303941[source]
So many gems in here but this one about microservices is my favorite:

grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

replies(8): >>44304390 #>>44304916 #>>44305299 #>>44305300 #>>44306811 #>>44306862 #>>44306886 #>>44309515 #
default-kramer ◴[] No.44304916[source]
I'm convinced that some people don't know any other way to break down a system into smaller parts. To these people, if it's not exposed as a API call it's just some opaque blob of code that cannot be understood or reused.
replies(5): >>44304992 #>>44305050 #>>44307611 #>>44308060 #>>44310571 #
1. demosthanos ◴[] No.44305050[source]
> To these people, if it's not exposed as a API call it's just some opaque blob of code that cannot be understood or reused.

I think this is correct as an explanation for the phenomenon, but it's not just a false perception on their part: for a lot of organizations it is actually true that the only way to preserve boundaries between systems over the course of years is to stick the network in between. Without a network layer enforcing module boundaries code does, in fact, tend to morph into a big ball of mud.

I blame a few things for this:

1. Developers almost universally lack discipline.

2. Most programming languages are not designed to sufficiently account for #1.

It's not a coincidence that microservices became popular shortly after Node.js and Python became the dominant web backend languages. A strong static type system is generally necessary (but not sufficient) to create clear boundaries between modules, and both Python and JavaScript have historically been even worse than usual for dynamic languages when it comes to having a strong modularity story.

And while Python and JS have it worse than most, even most of our popular static languages are pretty lousy at giving developers the tools needed to clearly delineate module boundaries. Rust has a pretty decent starting point but it too could stand to be improved.

replies(3): >>44305396 #>>44307207 #>>44307716 #
2. giantrobot ◴[] No.44305396[source]
3. Company structure poorly supports cross-team or department code ownership

Many companies don't seem to do a good job coordinating between teams. Different teams have different incentives and priorities. If group A needs fixes/work from group B and B has been given some other priority, group A is stuck.

By putting a network between modules different groups can limit blast damage from other teams' modules and more clearly show ownership when things go wrong. If group A's project fails because of B's module it still looks like A's code has the problem.

Upper management rarely cares about nuance. They want to assign blame, especially if it's in another team or department. So teams under them always want clear boundaries of responsibility so they don't get thrown under the bus.

The root cause of a lot of software problems is the organization that produces it more than any individual or even team working on it.

replies(1): >>44310305 #
3. arkh ◴[] No.44307207[source]
> Developers almost universally lack discipline.

Or developers are given a deadline and no slack to learn the code base. So developers will tactically take the fastest route to closing their ticket.

replies(1): >>44307231 #
4. rkomorn ◴[] No.44307231[source]
This. You'll take "too long", you'll be told you're overthinking/overengineering, people will preach iterating, that done is better than perfect, etc.

It's not developers that lack discipline. It's CTOs, VPs, etc.

5. zelphirkalt ◴[] No.44307716[source]
I think languages without proper support for modules are worse off than Python. Python actually has pretty good support for modules and defining their boundaries (via __init__.py).
6. patrickmay ◴[] No.44310305[source]
[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?