Live data from Hacker News

Simple Systems Have Less Downtime

gkogan.co

41–50 of 271 posts

Re: Simple Systems Have Less Downtime

#41

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…

> when python code really fails, e.g. in a context with threading, you might as well burn the whole thing to the ground This sounds weird. Why burn the whole thing to the ground? You've got frames from all threads available. Why would it take days to resolve the issue? Why do you think it's easier to resolve it in common lisp?

[deleted]

Re: Simple Systems Have Less Downtime

#42

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.

Re: Simple Systems Have Less Downtime

#44
post #15
post #2

Every new programming style epiphany is an ad hoc, intuitively-specified, hazy restatement of the Unix Way.

If Unix is your yardstick for simplicity, that just shows how far we've come…

UNIX is very simple, it just needs a genius to understand its simplicity.

And it is 2020, I guess nowadays everybody understand how unix-like system works and how simple they are.

Re: Simple Systems Have Less Downtime

#45
post #15
post #2

Every new programming style epiphany is an ad hoc, intuitively-specified, hazy restatement of the Unix Way.

If Unix is your yardstick for simplicity, that just shows how far we've come…

I disagree. I have an entire compressed text file on the simplicity of the Unix way. Once I remember the tar flags to extract it, I'll post its contents here.

Re: Simple Systems Have Less Downtime

#46
I like the ship analogy from the article. The fact it is so robust is not because the system as a whole is simple, but because its components have well defined, narrow responsibilities and there are abstract interfaces between them, which hide a lot of complexity. You don't need to understand the internals of the pump to explain what it does, even though the actual internal technology may be quite complex and clever. Also you don't need to understand the internals of the pump to design a rudder. This is a property that many IT systems lack. Insufficient abstraction leads to a network of components where you can't reason about anything without understanding all of it. And such systems often break in weird ways.

Re: Simple Systems Have Less Downtime

#47
The author is not arguing for simplicity per se, but about being able to insert a human into a system that is normally automated. The example about the ship's steering system is perfect, actually. The system is not "simple" (if I were on a ship and the steering failed, I would be clueless), but it provides plenty of interjection points where a knowledgeable human can step in and either debug or fix the issue. It's those points that should be relatively simple - the whole system itself can be as complex as needed.

Your system should be testable, debuggable and it should allow a human to step in and take control if needed. An open system is generally better than a closed one.

Re: Simple Systems Have Less Downtime

#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 much depends on the design of the system. Maybe there's a reason for having multiple forms. If they all shared common architecture and the problem lies in what they share, it's not necessarily more difficult to troubleshoot many as opposed to just one.

Moving from Marketo to HubSpot is good and well - for now. What about years from now? How did they end up with such complexity with the Marketo solution? Both solutions and requirements evolve. Down the line, you could end up with the same difficulties with HubSpot. I think it depends in part on how the organisation handles change.

Lastly, I agree with the sentiment of Mateusz Górski, who commented on the page: is there any hard proof beyond anecdote to back up the article? If you expand the article's concept of a system to beyond just software, 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.

Re: Simple Systems Have Less Downtime

#50
I share the idea of the author, but I miss actual talk about how we can make things better. Because his arguments are also true when it comes to security.

What are alternatives to commonly used complex systems, like Docker/Kubernetes, Active Directory, Remote Access or just shared folder structures? How to keep the functionality of centralized management while making it simple? Would be happy to hear your thoughts on this.

Post reply on HN