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

Simple Systems Have Less Downtime

gkogan.co

Post reply on HN
Print view View original

101–110 of 271 posts

Re: Simple Systems Have Less Downtime

#101

Post by Brian_K_White »

carlmr wrote: post #3

>For example, an analytics dashboard built with a no-code analytics tool like Looker is likely to have more qualified people to fix it than one built with a patchwork of custom scripts and APIs. Nobody should have to pull data scientists or product developers away from their work to fix a bar chart. I don't have experience with Looker, but the unseen complexity of no-code tools often leads to very complex systems wit…

I think the point, actually we don't have to think, it was stated explicitly, is that if Looker breaks, you can easily switch to an alternative.

This was presented as the rationale quite plainly, so I don't understand why people are missing it.

Re: Simple Systems Have Less Downtime

#102

Post by Minor49er »

jyounker wrote: post #69
DecoPerson wrote: post #22

I like to “embrace complexity.” Any line of code, especially one that introduces a new concept, like a class or a method, is in “addition” to the root problem we’re trying to solve. The closer the code/data/org-processes/whatever matches the fundamental problems we’re trying to solve, the less complexity we introduce. However, you cannot “remove” complexity! A common mistake I see in software companies is using a sin…

My favorite variants of this phenomena are "let's just add a column instead of creating a new table" and "let's add a boolean argument instead of creating a new function."

Or worse: "we built a table for arbitrary key-value pairings, but now the value needs to be an array or object, so we'll store it as a JSON string"

Re: Simple Systems Have Less Downtime

#103

Post by thinkloop »

Reminds me a bit of home automation (which I enjoy). You manage a plethora of battery powered devices that need constant connection to finiky wifi with continuous access to your Linux server hub so that push and pull of data remains in tact so that you can have AI actuate a function through a "remote" - all to replace a light switch. Sometimes I wonder where this will end up. Might need 50 years before reliability and simplicity are up to par.

Re: Simple Systems Have Less Downtime

#104

Post by thesuperbigfrog »

jdc wrote: post #42
hyperion2010 wrote: post #25

The only language that I have worked with that realizes that in the real world simple is _always_ a lie, is common lisp. It is the only language that has actually embraced the fact that its designers/committee were not geniuses and provided the tools for dealing with the complexity of the system. When unix tools fail, hope that you are on a system where it is possible to get the symbols and/or the source code, and ev…

Sure lisp is a wonderful language, but let's not pretend there's no difference between incidental and accidental complexity.

Fred Brooks called it "essential complexity" and "accidental complexity"[1].

Essential complexity is inherent to problem being solved and nothing can remove it.

Accidental complexity is introduced by programmers as they build solutions to the problem.

Lisp is nice because eliminates a lot of the accidental complexity through minimal syntax and lists as a near-universal data structure.

1: http://worrydream.com/refs/Brooks-NoSilverBullet.pdf

Re: Simple Systems Have Less Downtime

#105

Post by z3t4 »

collyw wrote: post #31
z3t4 wrote: post #30

Sometimes the complexity is there for a reason. But if you can just start over, those reasons was not that important!? So don't hang on to functionality because it would be nice to have, you will have to pay the price for those features over and over.

Sometimes, but a lot of devs fetishise complex stuff. I disagree wit a lot of my tech leads decisions because he always wants to do the "most correct" way, whereas I want to keep things as simple as possible with the aim of keeping our code maintainable. For example, he wants to a add a graph database to the tech stack, while I realise that its one more thing to manage and potentially break and mongodb (that we alrea…

Things only get complexed if you mix them, like cords in a box. So you might be able to keep it simple as long as you do not have code that depends on both the databases, and that the two databases don't depend on each other.

Re: Simple Systems Have Less Downtime

#106

Post by ignoramous »

papito wrote: post #54

Instagram was what, 12 employees when they got sold for a gazillion dollars? They all could fit into a van. Because they kept their system simple. It was (and still is) a monolith. Now imagine that they decided to go the microservices way. Multiply that team size by 10 at least. Don't solve problems you don't have.

WhatsApp, similarly, had 30+ employees when they got acquired [0]. They built the fastest IM on the market with 450M+ users sending 1B+ messages everyday, and at one point surpassed Facebook in terms of number of images uploaded.

The engs they had were world-class, so really, I think, saying microservices (or latest-fad) get in the way etc is disingenuous since you also require world-class talent to begin with (if you're going to keep the team-size small and yet be able to manage crazy scale) and a competitor willing to pay through the nose for the acquisition.

[0] https://www.sequoiacap.com/article/four-numbers-that-explain...

Re: Simple Systems Have Less Downtime

#107

Post by jerf »

thesuperbigfrog wrote: post #104
jdc wrote: post #42

Earlier quoted context omitted.

Sure lisp is a wonderful language, but let's not pretend there's no difference between incidental and accidental complexity.

Fred Brooks called it "essential complexity" and "accidental complexity"[1]. Essential complexity is inherent to problem being solved and nothing can remove it. Accidental complexity is introduced by programmers as they build solutions to the problem. Lisp is nice because eliminates a lot of the accidental complexity through minimal syntax and lists as a near-universal data structure. 1: http://worrydream.com/refs/Br…

One of the traditional criticisms of Lisp, though, is that it lets programmers re-introduce a whole lot of accidental complexity in their Lisp code, and, worse, everyone introduces a completely different set of accidental complexities into their code.

Re: Simple Systems Have Less Downtime

#108

Post by couchand »

obscura wrote: post #49

There's way too much simplification and generalisation here, IMHO. "Choose tools that are simple to operate over those that promise the most features." Doing this very much depends on your requirements, doesn't it? What good is a simple-to-operate tool if it doesn't do what you need it to do? Sure, maybe you can simplify your requirements; then again, maybe not. The example of troubleshooting a whitepaper form very m…

> all you need is a hardware fault in a third-party hosting company with lousy support for your simple piece of software to be down for weeks.

I suspect the author would reply that you can just replace the hosting provider. Since the interface and division of responsibilities is clear, one host is completely replaceable with another.

Re: Simple Systems Have Less Downtime

#109

Post by gk1 »

csomar wrote: post #87

The author, probably, picked the worst example. Here is a pic: https://iro.nl/app/uploads/2018/12/P-67-onboard-the-BOKA-Van... No, the containership is not a simple system. It's very sophisticated one. It takes massive engineering effort (literally historical effort and knowledge) to build, massive resources for the material and outsourcing, very complex (like the pic) infrastructure in case of repair, satellites to…

Hey, author here.

My point is that simple-to-understand systems--not simple as in primitive--have less downtime, not that we shouldn't ever have complex systems. A container ship like the one in my article can be drydocked ("in the shop") for repairs and back on the water in less than two weeks. A nuclear-powered aircraft carrier cannot. So be mindful when you're building an aircraft carrier when a container ship would've sufficed.

By the way, most of the "complex" stuff in the photo--which isn't a container ship--is scaffolding and piping.

Source: Got a naval architecture degree and a marine engineering license, operated a steamship for six months at sea, and designed ships for the US Navy for three years before abandoning ship to work with startups.

Re: Simple Systems Have Less Downtime

#110

Post by [deleted] »

ignoramous wrote: post #106
papito wrote: post #54

Instagram was what, 12 employees when they got sold for a gazillion dollars? They all could fit into a van. Because they kept their system simple. It was (and still is) a monolith. Now imagine that they decided to go the microservices way. Multiply that team size by 10 at least. Don't solve problems you don't have.

WhatsApp, similarly, had 30+ employees when they got acquired [0]. They built the fastest IM on the market with 450M+ users sending 1B+ messages everyday, and at one point surpassed Facebook in terms of number of images uploaded. The engs they had were world-class, so really, I think, saying microservices (or latest-fad) get in the way etc is disingenuous since you also require world-class talent to begin with (if yo…

[deleted]
Post reply on HN