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

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

medium.com

Post reply on HN
Print view View original

161–170 of 256 posts

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

#161

Post by dclowd9901 »

Oh the ideal.

At my last company, we had developed years ago an API layer that allowed outside developers to build plugins to our web app. We also created a market place in which these developers could host these plugins.

It was an absolute constant headache trying to tease out the bugs that these plugins would introduce. They often slowed the app down to a halt, and because they’re so opaque, users would blame us for the slow experience. I suspect it was because of the fact that their performance impact was so difficult to hold accountable, plug-in developers were never incentivized to make their plugins performant and just hacked them together.

And this is universal. Every app I’ve used with a sufficient amount of capability for extensibility will invariably suffer this problem. Slack and Figma also suffer from this issue after you’ve installed a bunch of plugins. They get really slow and bug out.

It is inevitable: the more code you add to something, the worse it gets.

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

#162

Post by dgb23 »

jacquesm wrote: post #107
freddie_mercury wrote: post #25

I think it is hard to reconcile this with the reality that every big billionaire dollar app does the complete opposite. Excel, Word, Jira, Salesforce, Facebook, Oracle ERP, etc.

I don't think there is a real contradiction. Once success gives you access to billions you no longer need to work the same way as you had to when you were much, much smaller. That's why as a small team it is wrong to adopt 'The Spotify model'. And yet, many companies will do just that. At every level of the corporate ladder there are different appropriate sets of tools and ways of working that will allow you to achie…

> Once you reach the Microsoft of the 1990's era level size (or Oracle, or SAP) you can ignore some of the truisms from the leaner days and do different things that would have killed a younger version of your company.

I think there are two sides of this.

There’s of course a much stronger need to integrate with established systems, no matter the unnecessary complexity, for those companies. They need to provide stronger compatibility guarantees as well as mitigate risk.

The other side is that once you have that many resources, it becomes less necessary to strive for simplicity and uniformity. The value for those companies shifted a long time ago from engineering to business processes.

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

#163

Post by dclowd9901 »

fefe23 wrote: post #83

Came looking for insights, found none. Instead I got platitudes like "sometimes microservices work well, sometimes not" and some copied together cartoon graphs, with a topping of meme pics. The conclusion is: "There are no easy answers". I wish I was kidding.

Notably the graphs didn’t make any sense to me. Don’t bugs go up as LOC go up? That’s my intuition at least.

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

#164

Post by discreteevent »

LeBit wrote: post #129
lijok wrote: 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.

Well, speaking for myself, I was against them from the start. Maybe the rejection of distributed objects (when it came) was a hot trend also but it didn't make it wrong.

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

#166

Post by rakoo »

This hub-and-spoke architecture is the core of acme, the editor of plan 9 aka "unix if it had evolved using its own mantras and didn't choose pragmatism all the time". That editor has extremely basic functions built-in, and more complex operations are done by external processes plugged to acme and accessing all buffers directly, with a good, mandatory usage of the mouse. Unfortunately it doesn't have all batteries included by default, so it's not very famous today.

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

#167

Post by vlz »

dclowd9901 wrote: post #163
fefe23 wrote: post #83

Came looking for insights, found none. Instead I got platitudes like "sometimes microservices work well, sometimes not" and some copied together cartoon graphs, with a topping of meme pics. The conclusion is: "There are no easy answers". I wish I was kidding.

Notably the graphs didn’t make any sense to me. Don’t bugs go up as LOC go up? That’s my intuition at least.

Yup, but who knows, that graph also doesn't even bother with a description on thy y-axis, maybe it is supposed to go from 0 "maximum bugs" (zero code non-buggy) all the way up to "no bugs" (all lines of code bug free). Or maybe the author just wanted something colorful for us to look at.

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

#168

Post by zer8k »

baz00 wrote: post #92
francasso wrote: post #48

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…

> If it's not that it's upgrading 100 services worth of dependencies constantly, debugging contract violations and weirdness or performance issues.

Of all the reasons microservices are bad this isn't it. Your first point can be handled mostly automatically with half decent SRE tooling. Lock files on any modern language (including Python via poetry) fix dependency weirdness. Contract violations are a problem with your developers not the style of programming. As for performance I've been on both sides and being able to independently scale microservices via kubernetes is a god send. With proper tooling microservices work great.

The real problem with microservices is what you mentioned before that IMO. Complexity for complexity's sake. Some things are better as monoliths and some things are better as microservices. It's the same problem you see with normalization vs denormalization. Microservices are unambiguously faster in almost all cases. "Do one thing" means that one thing can be optimized to death, in isolation, without fear of interrupting other services. It also means team structures are easier to manage. Microservices don't mean pull in the entire universe of RESTful libraries and use exactly one feature for 1 or 2 endpoints.

But this introduces another problem:

A second managerial problem is that microservices are often used in scrappy startups with overapplication of microservices to every problem that is the source of most woes.

Startups will religiously apply microservices. The thought, of course, being that they can hire/fire faster and an outsourced engineer can probably pick up the necessary work quicker. Of course, this never happens, because instead of 10 microservices you have 300 and no one even knows where half of them are. 99% of the time it's not the pattern that is the problem. It's cargo culting. Just like everything else in the industry (looking at you electron, leetcode, functional programming, agile, etc).

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

#170

Post by eesmith »

mawadev wrote: post #71
eesmith wrote: post #27

What's so different about Obsidian that sets it apart from previous plugin-based architectures? In particular, what is true about Obsidian which wasn't true about Eclipse some 20 years ago?

The marketing department sets it apart

Could you elaborate? I think your comment is meant in jest, but as both the Eclipse and Obsidian have marketing departments, I don't know how to interpret it.
Post reply on HN