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

211–220 of 220 posts

Re: Simple Systems Have Less Downtime (2020)

#211

Post by namaria »

api wrote: post #197
namaria wrote: post #170

Earlier quoted context omitted.

Simplicity is a name for isolated complexity only if there is as little unnecessary complexity as possible? You can only contain intentional complexity. I think you are agreeing with me.

I think you're underestimating the amount of inessential unnecessary complexity in most software and systems designs. There is a lot that can be trimmed without touching required complexity.

Did I say anything contrary to what you just stated at any point? I literally said simplicity is an illusion, just a name for tamed complexity.

Re: Simple Systems Have Less Downtime (2020)

#212

Post by bryanrasmussen »

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.

this relates https://news.ycombinator.com/item?id=28047618 if the giants are generating exabytes per year it seems reasonable to expect that your smaller application can end up with a few terabytes in the same time.

Re: Simple Systems Have Less Downtime (2020)

#214

Post by Aqueous »

Buttons840 wrote: post #162
Aqueous wrote: post #153

Earlier quoted context omitted.

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…

> I have started to make noise about the incentives being askew Choosing the hard path again I see.

Haha, yep. I just think it's fundamentally unjust for the developers doing the (easiest) green field development to get promoted while making significant architecture mistakes, then punishing later developers for pointing out those mistakes and getting stuck with fixing them. Until someone makes noise, this is just going to keep happening.

Re: Simple Systems Have Less Downtime (2020)

#215

Post by Aqueous »

shepherdjerred wrote: post #195
Aqueous wrote: post #153

Earlier quoted context omitted.

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…

I've had this exact same experience. Half-baked, unmaintainable features are launched. The developers get promoted and leave the team. The team is left to clean up and pay the consequences until development speed slows to a crawl. The team isn't able to get promoted because they're busy doing boring, undervalued work. The engineers responsible for the mess ultimately end up ahead. If your goal is to get promoted then…

Precisely. If I were to have neglected to point out the issue, or refused to lead the fix, I would probably have been promoted by now. Instead I chose the hard path and got punished for it. However, the team will benefit far into the future because they will no longer be fighting a schema that was just wrong. The only cost they had to pay was my career velocity.

Re: Simple Systems Have Less Downtime (2020)

#216

Post by Aqueous »

octopoc wrote: post #178
Aqueous wrote: post #153

Earlier quoted context omitted.

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

I will say, in this case it is not what happened. The previous system launched successfully with an incorrect schema. The platform grew and when it came time to add more features, some of them were either impossible to do because of the incorrect schema, or they would have been so complex to implement that the system would have fallen apart. Needless to say, the schema needed to be corrected, but the wrong schema was already baked in all across the platform.

So it's not like the main developer handed something off that was unfinished. They handed something off that was finished but wrong. And because of that we had to replace the engine while in flight, so to speak.

Re: Simple Systems Have Less Downtime (2020)

#217

Post by api »

dominotw wrote: post #123
api wrote: post #52

Earlier quoted context omitted.

> Even though it was so much fun That’s the root of quite a bit of evil in software. A closely related motive is a desire to show off. Play is good for learning but not for production systems. You’ll regret it later when you are up at 4am on a Sunday morning troubleshooting some Byzantine stack. The antidote is the realization that simplicity is harder than complexity. Simple but highly effective systems are the ones…

> That’s the root of quite a bit of evil in software. A closely related motive is a desire to show off. Yes but its also driven by keeping oneself employable. " I built a simple system to do X" is not a winning conversation in an interview. GP's complex system is what ppl say they built.

That's not how you frame it. You don't say simple, you say efficient. "I built a highly efficient system to do X that required only $$$ in monthly cloud spend and handled NN operations per second..."

You can also point out how fast you built it, since simpler systems often take less time.

Re: Simple Systems Have Less Downtime (2020)

#218

Post by [deleted] »

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…

[deleted]

Re: Simple Systems Have Less Downtime (2020)

#219

Post by hibbelig »

kaba0 wrote: post #36
zgniatacz wrote: post #24

“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…

I don't understand how they could classify CSV in the "less harmful" column -- its rules are insanely complex.

Also, UTF-32 seems way simpler conceptually than UTF-8, so I don't understand how UTF-8 ended up "less harmful" and UTF-32 ended up "harmful".

Re: Simple Systems Have Less Downtime (2020)

#220

Post by scythmic_waves »

Verdex wrote: post #202
bob1029 wrote: post #198

Earlier quoted context omitted.

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…

Your cardboard skyscraper analogy is fantastic. It does a good job capturing the tone of my disbelief.

I'm disappointed to see there wasn't a response because I was pretty willing to entertain the notion of business-logic-as-normalized-tables. But I needed, like, any evidence.

Post reply on HN