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

Re: Simple Systems Have Less Downtime (2020)

#171

Post by acdha » Wed, Aug 04, 2021, 5:01 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…

> 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.

It's not so simple — I've seen people create over-architected monsters because they thought everyone coded like some consultant's magazine article/talk/book claimed, because they were trying to be taken seriously and didn't think they could push back, because they had talked their way into a job they weren't qualified for and tossing around buzzwords was a way to obscure the fact that they had no idea what they were doing, because the client insisted that all real projects must run in the way the consultants in expensive suits assured them everyone serious runs them (ignoring massive differences in scope and resources or long term success), or because the institutional incentives made it easier to say their project would handle everything anyone had ever thought might be useful into one application rather than working with the actual users to build multiple smaller, simpler tools.

One way to think about that is that it's neither accidental nor essential complexity but environmental. Fixing that can be quite hard but it's often work the political capital if you have it because the alternatives might not be survivable.

Re: Simple Systems Have Less Downtime (2020)

#172

Post by Spivak » Wed, Aug 04, 2021, 5:08 PM UTC

bryanrasmussen wrote: post #140

BoiledCabbage wrote: post #82

Earlier quoted context omitted.

> 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.

At last $dayjob we were a speck compared to even the smallest "webscale" consumer B2C app and we gathered 800mil tracing events a week.

Re: Simple Systems Have Less Downtime (2020)

#173

Post by nodejs_rulez_1 » Wed, Aug 04, 2021, 5:11 PM UTC

dean177 wrote: post #156

nodejs_rulez_1 wrote: post #57

Earlier quoted context omitted.

I remember one dev kept talking about simplicity, even made a session about it and then just lumped business logic, data access and transfer layer mapping into a single API file...

Whats the problem?

Only works for small projects, doesn't scale in terms of maintenance.

Same sort of issue makes people use microservices not because of their true advantages but simply to enforce boundaries between features because so many people lack discipline to make a well-structured (distributed) monolith.

Re: Simple Systems Have Less Downtime (2020)

#174

Post by scruple » Wed, Aug 04, 2021, 5:12 PM UTC

papito wrote: post #161

henning wrote: post #145

Not building what doesn't need to exist won't get you promoted. You don't get promoted by avoiding entire classes of problems with a simple, reliable system. You get promoted by pulling heroics to build some absurdly complex cloud Kubernetes bullshit, and then pulling more heroics to fix the endless stream of production issues that will result from your overengineered nightmare.

"Complexity kills" is an old mantra a lot of us fossils are familiar with, but the new kids still need to learn this lesson the hard way. What makes things worse is the ability to stitch together twenty different AWS services together because - well - you can . Solving hard problems in simple and maintainable ways, I would argue, IS the job. But what I see is engineers solving problems they don't even have, for THIS…

The cargo cult mentality is the thing that I've seen throughout my career. FAANG does it this way therefore we must do it this way (I've also heard it parroted at the senior leadership and executive levels more than once!). IMO, this is the driving force behind juniors and intermediates who pull too much complexity into their solutions.

Re: Simple Systems Have Less Downtime (2020)

#175

Post by endisneigh » Wed, Aug 04, 2021, 5:15 PM UTC

nodejs_rulez_1 wrote: post #173

dean177 wrote: post #156

Earlier quoted context omitted.

Whats the problem?

Only works for small projects, doesn't scale in terms of maintenance. Same sort of issue makes people use microservices not because of their true advantages but simply to enforce boundaries between features because so many people lack discipline to make a well-structured (distributed) monolith.

Without knowing the problem it’s hard to say if they were right or wrong to do that.

Re: Simple Systems Have Less Downtime (2020)

#176

Post by rojobuffalo » Wed, Aug 04, 2021, 5:16 PM UTC

dredmorbius wrote: post #76

One of my hobbies is tracking down the origin of concepts and phrases. One such phrase is "complexity is the enemy", which I'd first encountered through the Jargon File, though it appears elsewhere, e.g., http://www.neugierig.org/software/blog/2011/04/complexity.ht... Tracing that trough Google's Ngram Viewer, I found the extended form, "complexity is the enemy of reliability " in a short item in a 1959 issue of The…

i like your hobby. i agree fewer parts is part of the definition of simplicity. i'd suggest "predictability" fits somewhere in the definition as well, in the sense that when you make a change to the system you can predict the outcome or side-effects; also, a person reasoning from first (or fewer assumptions) will have an easier time predicting the design of the system

Re: Simple Systems Have Less Downtime (2020)

#177

Post by nodejs_rulez_1 » Wed, Aug 04, 2021, 5:27 PM UTC

endisneigh wrote: post #175

nodejs_rulez_1 wrote: post #173

Earlier quoted context omitted.

Only works for small projects, doesn't scale in terms of maintenance. Same sort of issue makes people use microservices not because of their true advantages but simply to enforce boundaries between features because so many people lack discipline to make a well-structured (distributed) monolith.

Without knowing the problem it’s hard to say if they were right or wrong to do that.

I just know that "divide and conquer" works and impure functions with side effects don't.

Re: Simple Systems Have Less Downtime (2020)

#178

Post by octopoc » Wed, Aug 04, 2021, 5:42 PM UTC

Aqueous wrote: post #153

Jtsummers wrote: post #147

Earlier quoted context omitted.

http://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01_... I've posted this here before, though got no comments. But yes, firefighter/arsonists get more promotions and kudos than careful thinkers who don't bother setting fires to fight. EDIT: One past discussion here (2015): https://news.ycombinator.com/item?id=8940820

It is very bad. I spent the last year or so rebuilding a system with a fundamental architecture error that it would likely be fighting against for decades. My reward? The refactor was so difficult to do that I ended up getting dinged on timeline. And promotions got delayed The incentive structures at big companies are out of whack. Instead of the original developer, who was promoted to staff engineer, gettting dinged…

It's a big red flag when a dev makes something really cool that is (according to them) 90% done, then hands it off to someone else to finish. It's a sign that they:

1. Can't finish what they started

2. Are going to rewrite stuff unnecessarily

3. Are willing to throw their coworkers under the bus

Re: Simple Systems Have Less Downtime (2020)

#179

Post by jtdev » Wed, Aug 04, 2021, 5:43 PM UTC

henning wrote: post #145

Not building what doesn't need to exist won't get you promoted. You don't get promoted by avoiding entire classes of problems with a simple, reliable system. You get promoted by pulling heroics to build some absurdly complex cloud Kubernetes bullshit, and then pulling more heroics to fix the endless stream of production issues that will result from your overengineered nightmare.

Technical employees who frequently act like firefighters (especially those that draw attention to themselves when doing so, i.e., the martyr types) are toxic and should be removed ASAP.

Re: Simple Systems Have Less Downtime (2020)

#180

Post by flatline » Wed, Aug 04, 2021, 5:44 PM UTC

henning wrote: post #145

Not building what doesn't need to exist won't get you promoted. You don't get promoted by avoiding entire classes of problems with a simple, reliable system. You get promoted by pulling heroics to build some absurdly complex cloud Kubernetes bullshit, and then pulling more heroics to fix the endless stream of production issues that will result from your overengineered nightmare.

Is k8s really considered that complex? Yes, you need a lot of tooling to go from code to orchestration. But when you are commoditizing software to run on a desktop, on prem, in the cloud, across many customers and topologies, reproducible deployments are way simpler than hand-rolled whatevers.