“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
"complexity sells better" AWS sales team :)
Simple Systems Have Less Downtime (2020)
61–70 of 220 posts
Re: Simple Systems Have Less Downtime (2020)
#62People don't go out of their way to build complex systems. What happens is that it starts simple and becomes complex as more features are added often with limitations attached e.g. time, money etc. So yes this guy migrated from Marketo to Hubspot and it was simple. But the idea it will simply remain that way is laughable.
You can started from a complex system by using hyped (popular) technologies X, Y, Z. They may be good, but not necessary in every single case. People like complex tools because they look good on CV. And when everyone around uses them it feels like you are doing thing wrong if you have a simpler solution. Just add K8s to the mix and you are starting from a relatively complex system.
> People like complex tools because they look good on CV
Is this really a thing? I have yet to see a single case of it.
OTOH what I found more often than I could count is the belief that complex systems or tools are necessary because the problem is complex (it isn't) and the company's situation and requirements are so special (they aren't) -- not intentionally but simply due to lack of time and lack of contemplation of the problems and available solutions.
Re: Simple Systems Have Less Downtime (2020)
#63The Author generalized "fewer features lead to less downtime" to "simple systems have less downtime". A simple system such as a hand-written web server is very likely to crash. It's very likely cannot serve many users if we don't make it serve requests concurrently. What's worse, one tiny exception in one request would bring the whole system down. It stops serving any request to any user. A relatively complex system…
> A simple system such as a hand-written web server is very likely to crash.
> Kubernetes is complex, and it definitely gives us less downtime than simple scripts we have written before we use Kubernetes
There is a point in between 100LoC hand-written web server and K8s cluster. E. g. you need to serve static files and load is small to moderate (say 1. Create a K8s cluster where HTTP traffic will be dynamically proxied to a container running on some set of nodes reading files from GlusterFS cluster.
2. Install nginx on a pair of physical servers (with disk configuration depending on the load: from HDD mirror to SSD RAID 10) and something like CARP for HA IPs shared between them.
2nd option is much simple and in most cases will be more reliable: in theory K8s option can have higher availability but it requires much more effort to not screw up something and much harder to troubleshoot when something goes wrong.
Re: Simple Systems Have Less Downtime (2020)
#64When people face a new problem they intuitively try to find something they can add as a solution, not thinking about what they can remove to prevent the problem from occurring in the first place. This becomes apparent in the way marketing works. You sell products by promising they will solve a problem. You don't sell things by telling people what they really need to hear, that they just need less of everything. Simpl…
> "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."
- Antoine de Saint Exupéry
Re: Simple Systems Have Less Downtime (2020)
#65“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…
> accidental and essential complexity
I feel like I am turning into a bot for posting the Out of the Tar Pit paper:
http://curtclifton.net/papers/MoseleyMarks06a.pdf
This changed my understanding of computer science and our product virtually overnight. We are using a hybrid model of Functional Relational Programming (see section 9 in the paper). This is in production right now and its clearly the right answer for managing complexity in our product.
If you think "eww i have to learn some FRP language" - No. You just need to tack SQLite onto whatever preferred language you use today and model all your business logic as SQL queries over properly-normalized tables. If you can achieve this with 6NF, you have an infinitely-extensible domain model. If you don't know where to start, 3NF is the safest place. Most humans tend to think in terms of 3NF when referring to the business entities.
Re: Simple Systems Have Less Downtime (2020)
#66“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" 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.
Re: Simple Systems Have Less Downtime (2020)
#67Earlier quoted context omitted.
You can started from a complex system by using hyped (popular) technologies X, Y, Z. They may be good, but not necessary in every single case. People like complex tools because they look good on CV. And when everyone around uses them it feels like you are doing thing wrong if you have a simpler solution. Just add K8s to the mix and you are starting from a relatively complex system.
> People like complex tools because they look good on CV Is this really a thing? I have yet to see a single case of it. OTOH what I found more often than I could count is the belief that complex systems or tools are necessary because the problem is complex (it isn't) and the company's situation and requirements are so special (they aren't) -- not intentionally but simply due to lack of time and lack of contemplation…
Well, I don't think anyone would openly tell what they prefer shiny X to boring Y because X would look good on CV. It's just an impression I'm getting sometimes.
But what I've seen multiple times: someone is enthusiastic about a new technology and advocates for using it in a project at $job even when a simple, but equally or better suitable for the task option is available.
It may sound offensive, but my impression is that many developers are like children - they like to play with new toys and quickly bored by old. And in software industry they have an opportunity to choose new toys and be paid for playing with them.
Also I've seen many discussions on social networks where people talk that nowadays it is hard to find a good job if you don't have X, Y, Z on your CV so they may feel pressured to try these new tools even if they don't enthusiastic about them.
Re: Simple Systems Have Less Downtime (2020)
#68I'm an architect and I keep things simple too. The problem I have is people around me expect more complex/intricate solutions. They think simple is not sophisticated and savvy. They think the competition is ahead of our 'old, simple solutions'. I have to continually justify and explain that KISS is always the right approach.
Well, it's a trade-off, isn't it? Complexity can result from features which pay for themselves. Complexity is not automatically always wrong. At scale, complexity solves problems that you might not otherwise realize exist. Some of these problems are intrinsically complex, they can't be solved with a simpler solution. Not without "simple" organically growing into a much worse mess than the dominant complex solution th…
People don’t always agree on what simplicity is. To some, older proven technology is simpler, even if it requires more time, hustle and code to use. To the other, the same problem solved with a newer intricate tech, but solved quicker and leaner, is a simpler solved problem.
Re: Simple Systems Have Less Downtime (2020)
#69“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
Most technical people don't get paid to solve problems, they get paid to work on problems. That paycheck is an hourly/weekly/monthly paycheck.
Re: Simple Systems Have Less Downtime (2020)
#70That’s why I like Hacker News front end