Kernighan and Pike were right: Do one thing, and do it well • Hacker News Board

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

#221

Post by HumblyTossed » Sat, Aug 19, 2023, 6:56 PM UTC

> Big monolithic apps have large codebases that slow down development velocity. They’re slower to compile, harder to test, and full of dark corners where bugs can lurk and multiply. A bad change to one part of a codebase can cause headaches for an entire building’s worth of developers, tanking productivity for hours or days.

This has NOTHING to do with monoliths. If you cannot architect a monolith, you’re going to have a hell of a time with micro services. This just comes down to being an awful software engineer.

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

#222

Post by aswanson » Sat, Aug 19, 2023, 7:01 PM UTC

jmull wrote: post #209

Here’s the actual good advice: Build your system as a set of composable parts. The article doesn’t really quite get there, but is close. Almost everything else in there is wrong and should be ignored. Let’s see… *nix command line never did follow DOT, that’s the definition of shitty, not enshitification, the graphs are pulled out of thin air and represent the author’s feeling, not data, microservices don’t solve prob…

Amen. The only thing I'd add is "independently debuggable composite parts."

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

#223

Post by gardenhedge » Sat, Aug 19, 2023, 7:07 PM UTC

HumblyTossed wrote: post #221

> Big monolithic apps have large codebases that slow down development velocity. They’re slower to compile, harder to test, and full of dark corners where bugs can lurk and multiply. A bad change to one part of a codebase can cause headaches for an entire building’s worth of developers, tanking productivity for hours or days. This has NOTHING to do with monoliths. If you cannot architect a monolith, you’re going to ha…

A monolith has more engineers working on it though and chances are some of them won't be great.

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

#224

Post by tracerbulletx » Sat, Aug 19, 2023, 7:16 PM UTC

gardenhedge wrote: post #223

HumblyTossed wrote: post #221

> Big monolithic apps have large codebases that slow down development velocity. They’re slower to compile, harder to test, and full of dark corners where bugs can lurk and multiply. A bad change to one part of a codebase can cause headaches for an entire building’s worth of developers, tanking productivity for hours or days. This has NOTHING to do with monoliths. If you cannot architect a monolith, you’re going to ha…

A monolith has more engineers working on it though and chances are some of them won't be great.

It has nothing to do with individuals not being great, organizations of perfectly talented well intentioned people still end up with a mess eventually.

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

#225

Post by throwaway894345 » Sat, Aug 19, 2023, 7:21 PM UTC

HumblyTossed wrote: post #221

> Big monolithic apps have large codebases that slow down development velocity. They’re slower to compile, harder to test, and full of dark corners where bugs can lurk and multiply. A bad change to one part of a codebase can cause headaches for an entire building’s worth of developers, tanking productivity for hours or days. This has NOTHING to do with monoliths. If you cannot architect a monolith, you’re going to ha…

I don’t think this is true. I’ve seen the same 30-odd engineering team build a horrible monolith and a pretty decent microservice architecture. The difference between the two was that it was very easy to cheat in the monolith world—it was expedient to patch in some feature by giving access to some thing which ought to be private in one component and that shortcut was often commanded by management (often with promises that We Will Definitely Prioritize Fixing Properly Next Sprint). Microservices make this sort of cheating more difficult than doing the proper thing, so management and their yes-men don’t have an incentive to cheat in that particular way.

Another reason things were cleaner was because we could write components in the language that was best suited for it. In our monolith version, everything had to be Python because we essentially needed its data science ecosystem, but that meant every other component in the system was fighting against Python’s package management, performance, and reliability problems for no material gain.

I think you can get similar rails in a monolith world via strict anti-shortcut culture, but technical controls are a lot easier than political controls IMHO. Similarly, you could probably build some Frankenstein FFI regime in a monolith to support multiple languages, but that seems strictly worse from a maintainability perspective.

All that said, there are definitely costs to building with microservices—I’m not saying they’re a panacea or even better than monoliths in the general case, I just don’t buy the “if you can’t do it in monolith you won’t be able to do it with microservices” line.

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

#226

Post by UltimateEdge » Sat, Aug 19, 2023, 7:47 PM UTC

zer8k wrote: post #168

baz00 wrote: post #92

Earlier quoted context omitted.

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…

Why did you include functional programming in that list? It seems like the odd one out to me.

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

#227

Post by grumblingdev » Sat, Aug 19, 2023, 7:48 PM UTC

vlz wrote: post #202

The way in which microservices, unix programs and extensible editors in this article are compared as if they are all attempts or at least examples of how to somehow "solve software architecture" is really rubbing me the wrong way. The author is speaking as if "How to organize software" is the nail and these things are all attempting to be hammers when they are really not. Would I want to build a world wide streaming…

> "How to organize software"

I have recently had the thought that this is mostly what software architecture is...at some level.

It's about where we draw the boundaries around code to make it easy for humans to understand.

Imagine taking an existing repo, and extracting every block of code into a function, and then moving them into their own separate file in one big folder. You could extend it to all the libraries of your code, and of those services we communicate with over the network too.

This would look a bit like a debugger symbol table. It's closer to how the computer understands the program.

The app still runs. It's just hard for people to understand what is going on.

Software architecture is simply the grouping of these functions to some extent.

It's not a foolproof analogy, because there are some decisions to be made about implementation details of things, but at some level of abstraction you would find the same operations need to be run.

Just an interesting thought.

> The question of how to architect such software is still an open one.

I find a problem we face with architecture discussions is that its always about tradeoffs that are not immediately apparent.

And it takes a lot of mental effort to remember why something is a bad idea.

The way we discuss it is limited by plain text. It's hard to demonstrate a system evolving over time in a concise manner.

Architecture should be evaluated by throwing a spec at it, and then changing every part of the spec (including adding perf requirements) and seeing how long it takes to make the changes, and how many bugs it has.

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

#228

Post by grumblingdev » Sat, Aug 19, 2023, 8:03 PM UTC

aswanson wrote: post #222

jmull wrote: post #209

Here’s the actual good advice: Build your system as a set of composable parts. The article doesn’t really quite get there, but is close. Almost everything else in there is wrong and should be ignored. Let’s see… *nix command line never did follow DOT, that’s the definition of shitty, not enshitification, the graphs are pulled out of thin air and represent the author’s feeling, not data, microservices don’t solve prob…

Amen. The only thing I'd add is "independently debuggable composite parts."

I would prefer "end-to-end debuggable...". The biggest casualty of the web-scale era.

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

#229

Post by grumblingdev » Sat, Aug 19, 2023, 8:04 PM UTC

HumblyTossed wrote: post #221

> Big monolithic apps have large codebases that slow down development velocity. They’re slower to compile, harder to test, and full of dark corners where bugs can lurk and multiply. A bad change to one part of a codebase can cause headaches for an entire building’s worth of developers, tanking productivity for hours or days. This has NOTHING to do with monoliths. If you cannot architect a monolith, you’re going to ha…

Usually tooling related. I don't know what language you can pick today that is not a complete shit-show for dependency management.

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

#230

Post by grumblingdev » Sat, Aug 19, 2023, 8:18 PM UTC

noelwelsh wrote: post #8

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'…

> My copy of `ls` has at least 40 flags

Good point.

You have to hand it to them though, that shell commands are still the least-typing way to do something compared to every programming language out there.

Like if you gave the user an always-on JavaScript or Python repl, shell commands are still going to win every time.

There are so many JS functions I have that I wish would just get automatic cli interfaces...instead of having to go through the ceremony, or use a repl, or something like that.