Live data from Hacker News

Kernighan and Pike were right: Do one thing, and do it well

medium.com

131–140 of 256 posts

Re: Kernighan and Pike were right: Do one thing, and do it well

#131

You don't need a damn network between two pieces of code just to "do one thing and do it well", for God's sake, I'm so sick of this rampant cluelessness in the industry. Do you saturate the resources of one machine and need to split things off? Do you have multiple teams each taking care of their own stuff? Do multiple services, it's fine in those cases. For almost any other reason you are just adding complexity, boi…

> Do you saturate the resources of one machine and need to split things off? No, of course not. We divide a single machine in an uncountable number of virtual ones; write some code to make sure they don't talk to each other; write some code to make them able to talk to each other; write some code make more or fewer divisions on the run, automatically; and write some code so we can set them up automatically too every…

None of those things require you to introduce network calls.

Re: Kernighan and Pike were right: Do one thing, and do it well

#132
post #129
post #101

Earlier quoted context omitted.

What specifically do they not solve? Because in this thread we're, very specifically, discussing isolating the well maintained monolith from risky product produced by consultants, which microservices absolutely do solve.

I think the hot trend these days is to bash on microservices. I hear that a lot here, random blogs, youtube videos by self proclaimed top guns. If hacker news is correct, microservices is the #1 worst idea of software engineering. And whoever promotes them is either a kid with no experience or a complete moron.

[deleted]

Re: Kernighan and Pike were right: Do one thing, and do it well

#133

You don't need a damn network between two pieces of code just to "do one thing and do it well", for God's sake, I'm so sick of this rampant cluelessness in the industry. Do you saturate the resources of one machine and need to split things off? Do you have multiple teams each taking care of their own stuff? Do multiple services, it's fine in those cases. For almost any other reason you are just adding complexity, boi…

> Do you saturate the resources of one machine and need to split things off? No, of course not. We divide a single machine in an uncountable number of virtual ones; write some code to make sure they don't talk to each other; write some code to make them able to talk to each other; write some code make more or fewer divisions on the run, automatically; and write some code so we can set them up automatically too every…

And what if a certain permutation of these hundreds of services goes down or slows down? What if one service starts generating tons of data and floods another service? Do you have backpressure figured out? Distributed systems introduce a whole new level of complexity and edge cases, but most companies never even hit the scale at which it matters. It's just a pointless, wasteful exercise in "how they do it over at Google".

Re: Kernighan and Pike were right: Do one thing, and do it well

#134
The difficulty with the plugin model is that it tends to be brittle with regards to change. You need to have very well-abstracted, succinct and stable interfaces that don’t prohibit changes in the main application too much. It’s also difficult to prevent plugins from relying on various implementation details that aren’t part of the interface contract. If plugins have to be regularly updated for new application versions, that only leads to constant churn and abandoned plugins. It means the architecture effectively isn’t truly modular.

Re: Kernighan and Pike were right: Do one thing, and do it well

#135

You don't need a damn network between two pieces of code just to "do one thing and do it well", for God's sake, I'm so sick of this rampant cluelessness in the industry. Do you saturate the resources of one machine and need to split things off? Do you have multiple teams each taking care of their own stuff? Do multiple services, it's fine in those cases. For almost any other reason you are just adding complexity, boi…

"grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug" -- https://grugbrain.dev

Fuck agile and 10x DevOps developers.

Who's hiring grugs, the lazy programmers that try to do the most efficient thing in the least amount of work? I'm not smart enough to set up a whole georeplicated k8s cluster for your blog. I'll use Apache, maybe put Varnish if you get on the frontpage of HN, ok?

(Work smart, not hard. DevOps today is the exact opposite of that)

Re: Kernighan and Pike were right: Do one thing, and do it well

#136
post #104

Earlier quoted context omitted.

You let interns push to production without code review?

Totally missed the point. Even with Code reviews, Unit/Integration Testing, Automated CI/CD and more can a person broke the prod. One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it. If you think "why not restrict config actions" etc, it's because the dev can go there and tweak those actions too. And e…

> Automated CI/CD

[...]

> One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it.

These sound contradictory to me. Part of having automated CI/CD, is not having to manually deal with k8s to do a regular deploy.

Re: Kernighan and Pike were right: Do one thing, and do it well

#137
post #92

You don't need a damn network between two pieces of code just to "do one thing and do it well", for God's sake, I'm so sick of this rampant cluelessness in the industry. Do you saturate the resources of one machine and need to split things off? Do you have multiple teams each taking care of their own stuff? Do multiple services, it's fine in those cases. For almost any other reason you are just adding complexity, boi…

This. So much this. We are 5 years into a microservices wank-fest. So far the net ROI is negative, the user experience sucks more than ever, the complexity is so high that people can't get things done, nothing works properly any more and no one owns anything because they have washed their hands of it all. But this is still promoted as a success because no one wants to be accountable for the fuck up. Our team spend mo…

One thing I wonder is this:

There are companies that are very successful and have split their service architecture into domain entities, called microservices.

Are they successful because or despite this decision?

Is both true in some sense?

A more natural way to split up a server architecture is to use computational boundaries. These are found by thinking of how data is processed and flows through the system as opposed to separation of high level domain concerns.

But this requires a computational design and not a domain/feature centric one.

Re: Kernighan and Pike were right: Do one thing, and do it well

#138
post #102

Earlier quoted context omitted.

"grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug" -- https://grugbrain.dev

There is so much wisdom in here. Fundamentally, don't make life hard for yourself, or others.

When a company measures developer productivity in code added and feature delivered, it creates a perverse incentive that attracts people that really love to write a lot of code and building mountains out of molehills.

The best engineer (and not only, see that famous quote by Kurt von Hammerstein-Equord) often is the lazy one. It was a known notion that somehow disappeared around the turn of the millennium.

Re: Kernighan and Pike were right: Do one thing, and do it well

#139

Earlier quoted context omitted.

> Do you saturate the resources of one machine and need to split things off? No, of course not. We divide a single machine in an uncountable number of virtual ones; write some code to make sure they don't talk to each other; write some code to make them able to talk to each other; write some code make more or fewer divisions on the run, automatically; and write some code so we can set them up automatically too every…

And what if a certain permutation of these hundreds of services goes down or slows down ? What if one service starts generating tons of data and floods another service? Do you have backpressure figured out? Distributed systems introduce a whole new level of complexity and edge cases, but most companies never even hit the scale at which it matters. It's just a pointless, wasteful exercise in "how they do it over at Go…

Nothing that can't be solved with more code and more splitting! That will make things simpler! The more problems your code causes, the more code, the more solutions!

(Well, ok, I'm having a hard time solving the first one with more code, but did hear this claim applied to it more than once, so I'm keeping it general.)

There is a huge amount of people that sees nothing wrong with my rationale up there. I don't get it either.

Re: Kernighan and Pike were right: Do one thing, and do it well

#140

The basic point is right, but I think a lot of the details are off. The core idea is composition. A system is compositional if you can build it from small reusable parts. It's one of the key ideas in functional programming, and it's somewhat core to object-oriented programming. (OO is too big to be able to claim their is a consistent philosophy behind it.) But ... firstly, let's stop with the Unix worship. They didn'…

Composable systems have a very clear property: uniform interfaces.

CLI flags are typically arbitrary. What if they weren’t? How would they look like?

Post reply on HN