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

Simple Systems Have Less Downtime (2020)

gkogan.co

Post reply on HN
Print view View original

201–210 of 220 posts

Re: Simple Systems Have Less Downtime (2020)

#201

Post by scruple »

deckard1 wrote: post #189
scruple wrote: post #174

Earlier quoted context omitted.

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.

Yes, and I've commented about this again and again. The push for microservices, K8S, Docker. It's all the same thing. It all comes from Google. Or occasionally Facebook. We can thank them for many of the bad ideas of the past 20 years. Open floorplan offices. K8S could only have come from Google. It's a reflection of their corporate structure. Conway's Law and all that. Much like microservices. It's a reflection of t…

I was going to type out something about the lack of cohesive technical vision being a massive part of the problem but Conway's Law is far too succinct.

Re: Simple Systems Have Less Downtime (2020)

#202

Post by Verdex »

bob1029 wrote: post #198
Verdex wrote: post #186

Earlier quoted context omitted.

I want to second this. My first thought was the same as yours (no way that works for everything). It seems like a neat idea. But I can't imagine that anyone has ever done this for anything non-trivial. I want some sort of compelling argument that this works at all before I'm willing to accept this as anything else than a pipe dream.

I am curious what edge cases (i.e. "non-trivial" things) you have in mind that this would not work for. For us, the more complex the business gets, the more justified this path becomes. Our business fails to scale if we have to write custom code for every customer. Writing custom SQL per customer (against a common schema) is far more tenable. Are you thinking of some specific logical determination that would be infea…

It's the same sort of disbelief that I would have towards being introduced to a skyscraper made out of cardboard. At first I would think, "oh, this is just like concept art." ~No, we actually built it.~ "Err, so, like nobody can actually go in there." ~It supports people just fine.~ "Um, for what, 20 minutes." ~Well, Nick has lived in it for 20 years now.~

Finally, I'm not going to venture in (let alone actually live in it myself) without someone sitting me down and carefully explaining the structural integrity principles (and other logistics) that make the cardboard skyscraper possible.

Hearing business rules in sql works for some unknown entity doesn't really give any information about the viability for anything else. Maybe the initial modeling is really hard, but all your customers have near identical concerns, so you only pay that cost once. Maybe having multiple customers is actually the key because if one customer's needs violates some assumption that makes the whole thing work, you can tell them go to someplace else. Maybe your customers only have five business logic rules apiece that are all well spec'ed.

What's the domain? The industry? What problems are actually being solved? Can we have an example (even a contrived one)? Is there an open source example? How about a mathematical proof or even principle that argues for why this can be expected to always (or even nearly always) work? How about a youtube video with someone describing the approach?

EDIT: How about this. Show me a partial parser using this approach (grammar rules can be considered business logic, right). Just parse function declarations in C or something. I'll be able to project such an example onto what the full solution would look like to see if I believe it could actually work in general.

Re: Simple Systems Have Less Downtime (2020)

#203

Post by rixed »

jtdev wrote: post #179
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.

No more firefighters, no more fires! Qed.

Re: Simple Systems Have Less Downtime (2020)

#204

Post by nodejs_rulez_1 »

Raidion wrote: post #188
nodejs_rulez_1 wrote: post #177

Earlier quoted context omitted.

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

I mean, your statement assumes a definition for "work". Reusability and maintainability are features, and for certain scopes, they may be overkill. I think this is where the really good software developers shine: You have to know the rules before you break them for sure, but pretending there isn't opportunity costs in software development is a big problem. Shipping anything gets you feedback, and that feedback can dr…

I am a developer not a manager, getting resources is not my problem but maintaining bad code is. In the end of the day business does not understand technical debt, so it's my duty to manage it transparently and well in advance. Perhaps start-ups that need to capture market or something are a different story.

Re: Simple Systems Have Less Downtime (2020)

#205

Post by dredmorbius »

sitkack wrote: post #139
dredmorbius wrote: post #96

Earlier quoted context omitted.

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…

Is simplicity a fitness function?

Are fitness functions universal?

Re: Simple Systems Have Less Downtime (2020)

#206

Post by ocdtrekkie »

citrin_ru wrote: post #143
ocdtrekkie wrote: post #129

Earlier quoted context omitted.

I have read about a dozen and a half articles about capex vs. opex, and it still makes absolutely no sense to me why companies prefer paying over double for opex what they'd pay for equivalent capex over the same lifecycle. Either corporate accounting is some mystical art that makes money appear where there isn't if certain practices are followed, or there's some collective mass delusion that opex is just better? I d…

For a startup it makes perfect sense to avoid high CAPEX: it is not worth to invest into own infrastructure which will have positive ROI in 3 years, if you are not sure that you startup will still be alive in 3 years. Why big established companies prefer high OPEX to lower CAPEX is less clear.

Indeed, I fully understand why a startup goes for the cloud: Either it scales fast enough that the dynamic scaling of cloud is key, or it fails and assets become pointless anyways. But even then, once a startup hits a certain level of stability, it makes sense to invest in your own infrastructure to minimize expense.

Re: Simple Systems Have Less Downtime (2020)

#207

Post by gajjanag »

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…

And companies wonder why loyalty is hard to find...

Far easier to jump ship at opportune moments for fast tracking a career than fighting dysfunctional internal incentive structures.

Re: Simple Systems Have Less Downtime (2020)

#208

Post by dredmorbius »

rojobuffalo wrote: post #176
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

Predictability to me seems more a consequence of than a contributor to simplicity. Though there are very simple systems (e.g., three-body problem, double-pendulum) which exhibit highly unpredictable behaviours.

Re: Simple Systems Have Less Downtime (2020)

#209

Post by henning »

flatline wrote: post #180
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.

Kubernetes itself is not the problem. It's the DIY PaaS setups people build with YAML files, bash scripts, Jenkins jobs and webhooks that people build on top of it.

Re: Simple Systems Have Less Downtime (2020)

#210

Post by dredmorbius »

naasking wrote: post #85
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…

> 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

I'd extended a concept of Charles Perrow's a few months back on determinants of simplicity vs. complexity in systems, generally. See: https://joindiaspora.com/posts/97208f300fc4013901a3002590d8e...

(I think I may have swapped the ranges on "Threshold sensitivity", which seem more reasonably to be "low/high" than "high/low".)

Post reply on HN