Simple Systems Have Less Downtime (2020) • Hacker News Board

Re: Simple Systems Have Less Downtime (2020)

#131

Post by Jtsummers » Wed, Aug 04, 2021, 3:33 PM UTC

Zababa wrote: post #126

Jtsummers wrote: post #122

Earlier quoted context omitted.

Kolmogorov complexity is close to what you're getting at, but is about total string length of the program which is more useful than line count when line count can be gamed. That is, a shorter program is "simpler" than a longer program. In quotes because it's not necessarily true (see code golfing, the language itself may become very complex to permit such a short program and the requisite knowledge and competency the…

> There are also analysis methods (names escaping me, and Google fu is weak today) that look at loops, procedure calls, dependency graphs, and other things to attempt to discern (should be treated as guidelines and not rules) the complexity of a program using objective metrics. Cyclomatic complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity might be what you're thinking about.

That was it, thank you.

Re: Simple Systems Have Less Downtime (2020)

#132

Post by majormajor » Wed, Aug 04, 2021, 3:42 PM UTC

DanielBMarkham wrote: post #88

kaba0 wrote: post #36

Earlier quoted context omitted.

I think every talk on complexity is meaningless, without taking into account the difference between accidental and essential complexity. There are problem domains where there is simply a minimal complexity required implicitly. You can’t write an insanely simple program that will render vector fonts, simply because the problem inherently has to have a fixed amount of complexity. Anything more (accidental complexity) i…

>> I think every talk on complexity is meaningless, without taking into account the difference between accidental and essential complexity. Yeah. This is both true and pointless. Nobody codes things too complex on-purpose, at least not normal people. So it's not the difference in types of complexity, it's the difference in our ability to understand accidental and essential complexity. I find that I do a really poor j…

I've worked with a lot of people who'd never thought about the difference between accidental and essential complexity.

This resulted in them coding things too complex unintentionally, so while not on-purpose, it was absolutely a useful conversation to have. It's a good starting point.

I don't have a good single rule for a "second step," though. It's going to depend on the details of your project, by and large, though I think some principles to try to strive for include composition, encapsulation of details, and so on - nothing new or startling, but just adding the "is this essential or accidental" lens to the decision-making process.

Re: Simple Systems Have Less Downtime (2020)

#133

Post by rantwasp » Wed, Aug 04, 2021, 3:44 PM UTC

kaba0 wrote: post #36

zgniatacz wrote: post #24

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” – Edsger W. Dijkstra

I think every talk on complexity is meaningless, without taking into account the difference between accidental and essential complexity. There are problem domains where there is simply a minimal complexity required implicitly. You can’t write an insanely simple program that will render vector fonts, simply because the problem inherently has to have a fixed amount of complexity. Anything more (accidental complexity) i…

essential complexity == simplicity. Make it as simple as it can be but not simpler.

To me it’s sort of implied that it’s unneeded complexity when we talk about it as something that should not be there and it’s making our life hard.

Re: Simple Systems Have Less Downtime (2020)

#134

Post by lmilcin » Wed, Aug 04, 2021, 3:46 PM UTC

chousuke wrote: post #75

lmilcin wrote: post #15

It should really say "overcomplicated system tend to break more frequently". It is not simplicity that makes for less downtime, it is unnecessary complication that does the opposite. I spend time to complicate my applications a little bit to make sure there is no downtime, something pretty important when one of the largest banks on Earth will stop along with your application. The simplest solutions would typically no…

Regarding "no downtime", there are very few applications where that's actually a good goal to have at all. Quite often, simple systems can provide you high availability where your downtime is a few seconds or minutes at most (during larger maintenance operations), and in many cases you can hide those blips by simply retrying (with proper backoff). There aren't many systems where you actually need to guarantee "no dow…

There is more systems that can't tolerate downtime than you think. And this is mostly because you treat it as fabric of everything around you and you only notice when it fails.

Mobile networks? Power delivery (basically all utilities)? Broadband internet? Factories? Payment systems? Air traffic control? Any internet services at all?

One can think that only Google or Facebook need to maintain high availability, but basically any internet services needs to do that or face possibility of loosing clients.

Smaller company may have less clients but the downtime still affects their clients and in turn them the same way. Loosing 10% clients after snafu is as painful when you have 1 million clients as when you have 100 clients.

It is also not about having absolutely no downtime -- this usually cannot be guaranteed. It is about having less downtime.

Re: Simple Systems Have Less Downtime (2020)

#135

Post by [deleted] » Wed, Aug 04, 2021, 3:49 PM UTC

kaba0 wrote: post #36

zgniatacz wrote: post #24

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” – Edsger W. Dijkstra

I think every talk on complexity is meaningless, without taking into account the difference between accidental and essential complexity. There are problem domains where there is simply a minimal complexity required implicitly. You can’t write an insanely simple program that will render vector fonts, simply because the problem inherently has to have a fixed amount of complexity. Anything more (accidental complexity) i…

[deleted]

Re: Simple Systems Have Less Downtime (2020)

#136

Post by ratww » Wed, Aug 04, 2021, 3:52 PM UTC

titzer wrote: post #66

kaba0 wrote: post #36

Earlier quoted context omitted.

I think every talk on complexity is meaningless, without taking into account the difference between accidental and essential complexity. There are problem domains where there is simply a minimal complexity required implicitly. You can’t write an insanely simple program that will render vector fonts, simply because the problem inherently has to have a fixed amount of complexity. Anything more (accidental complexity) i…

"Essential" is always relative to requirements. If the requirements include interacting with a poorly-designed, buggy, complicated piece of other software, then yeah, you have essential complexity. Enlightenment is when you realize that you can keep zooming out and dumping what seem like essential requirements but are really just BS that follows from interacting with constantly-changing crapball software stacks.

Nah, that’s a cop out. There’s nothing enlightening about shrugging off complexity.

If a system is hard to interface with, the complexity is still accidental, it is just outside your own system and maybe out of your control.

Even if you’re a “middleware” company that connects multiple shitty systems together, you’re still adding zero value to anything but your own pocket. The complexity is still there.

We still have the right to call a spade a spade. In the past I had to say “no” to managers about interfacing with shitty systems. Sometimes you CAN make a difference.

Re: Simple Systems Have Less Downtime (2020)

#137

Post by ChrisMarshallNY » Wed, Aug 04, 2021, 3:53 PM UTC

This is sort of like the old "Water is wet; news at 11." thing.

But simple is not easy. In my experience, it often comes after complexity.

My general approach to simplification is to first get it working; even in a complicated fashion, then start removing stuff, until it stops working. If I can't get it working on the latest simplicity, I am forced to add the last thing back.

But I can usually get it going, which may sometimes require a rearchitecting.

One of the happiest times for me, when I'm writing code, is when I get to toss out a whole bunch of painstaking work that I did.

I'm going through that now. I'm working on an app that has necessary complexity, and I'm finding ways to toss out code all over the place.

Re: Simple Systems Have Less Downtime (2020)

#138

Post by Pokepokalypse » Wed, Aug 04, 2021, 3:53 PM UTC

trasz wrote: post #44

Sebb767 wrote: post #11

I think a better point would be "simple systems are quicker to fix" or, more concise, "avoid unnecessary complexity". In some way, complexity allows flaws to get in, but that does not mean it's unnecessary. Take, for example, website hosting. You can put your full page on a single server, but then you're prone to the machine going down, the disk having errors etc.. A more complex system, like Kubernetes, will be far…

Until recently even the huge airliners had physical strings going from the rudder all the way to the wing and tail control surfaces. Precisely because more complex systems were less reliable. Also, even with fly by wire there’s sometimes (or often, or always, no idea) a backup, eg a direct electric / hydraulic link.

sounds like the 737MAX. . .

Re: Simple Systems Have Less Downtime (2020)

#139

Post by sitkack » Wed, Aug 04, 2021, 3:54 PM UTC

dredmorbius wrote: post #96

naasking wrote: post #85

Earlier quoted context omitted.

> A full definition of "simplicity", as with "complexity", lies somewhat in the eye of the beholder. Perhaps "somewhat", but not entirely or arguably even mostly: http://curtclifton.net/papers/MoseleyMarks06a.pdf

Simplicity is simple to define for simple problems, but complex to define for complex ones.

Simplicity is a shape that composes or has symmetry in that dimension.

The greatest act of simplification I did was reduce the problem from a continuous one, some one wanted to filter on distance and I moved it to a set of three buckets.

This discounts all the things argued out of existence or replaced with a sql query.

Which reminds me, the longer you can keep something relational the larger your chance at reducing complexity, because you can project down to a lower dimensional space to solve specific problems. 80% of work is in choosing that right lower space and making the projection. Once there, all problems are flat.

Re: Simple Systems Have Less Downtime (2020)

#140

Post by bryanrasmussen » Wed, Aug 04, 2021, 3:57 PM UTC

BoiledCabbage wrote: post #82

eatonphil wrote: post #74

Earlier quoted context omitted.

The problem is that performance and normalization do not (always) go well together. Let's say you have billions of rows of event data you want to perform summary counts for by a few different key columns. Doing this up front as the events are ingested is going to allow for much more efficient querying on an already grouped table than having to group on your billions of events in each SELECT query. I'm not saying don'…

> The problem is that performance and normalization do not go well together. > Let's say you have billions of rows of event data you with to perform summary counts for by a few different key columns. Guess what? 99% of people on here don't have billions of rows of event data they need to regularly aggregate. Problem solved. Such a terrible tradition in our industry in focusing on outlier cases, or on what FB/Google/.…

>Guess what? 99% of people on here don't have billions of rows of event data they need to regularly aggregate. Problem solved.

having built a real time analytics solution a few years ago because we wanted one we controlled for our startup, it doesn't take much to get to billions of rows of event data in the modern web.