Live data from Hacker News

Simple Systems Have Less Downtime (2020)

gkogan.co

161–170 of 220 posts

Re: Simple Systems Have Less Downtime (2020)

#161

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 IS THE WAY. Also, there is a FAANG guy on the team that claims that's how they did it over there.

Re: Simple Systems Have Less Downtime (2020)

#162

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…

> I have started to make noise about the incentives being askew

Choosing the hard path again I see.

Re: Simple Systems Have Less Downtime (2020)

#163
post #21

Yes, let's replace these computers and smartphones with pen, paper and dumbphones.

If you were to do that, those "systems" would definitely have much less downtime.

It might not be as efficient or convenient, but that wasn't the question. If the efficiency of convenience of two competing system is sufficient, the less complex one will have fewer parts to fail, and cost less downtime.

So for example for a "who touched this cabinet last" sheet, pen and paper would indeed often be better than smartphones.

Re: Simple Systems Have Less Downtime (2020)

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

I don't think that this sort of selfish thinking is dominant. The explanation is much more simple - many in our field see complexity as a virtue, not an enemy.

Re: Simple Systems Have Less Downtime (2020)

#166
post #79
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 wrote a piece about that some time ago. The vast majority of the complexity in my professional career now is extra curricular complexity and that wasn't true a decade ago. It's build processes, it's CI, it's containers, it's a dozen arbitrarily different frameworks, microservices, dependency management, it's all of that stuff. The trope I see all the time is enterprise tooling in small projects. Small teams basical…

But I really enjoy painting bike sheds and shaving yaks!

YAGNI is so hard for people to really grok.

Get the revenue model right and suddenly every feature is cheap; get it wrong and every decision is infinitely expensive.

Re: Simple Systems Have Less Downtime (2020)

#168
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…

The more I think about it the more it seems to me 'simplicity' is just another name for 'encapsulated/isolated/modularised complexity'

This is only true if all the complexity is necessary and intrinsic to the problem. Simplicity means there is as little incidental (unnecessary) complexity as possible.

Re: Simple Systems Have Less Downtime (2020)

#169

I'm going to make a controversial claim for the sake of argument. We can and will debate what programs are "simpler" all day, it's all subjective... except for one metric: line count. Line count is objective. Take pause before rejecting any change that uses fewer lines of code. It takes an awfully good abstraction to beat simply having less code.

Kolmogorov complexity is close to what you're getting at, but is about total string length of the program which is more useful than line count when line count can be gamed. That is, a shorter program is "simpler" than a longer program. In quotes because it's not necessarily true (see code golfing, the language itself may become very complex to permit such a short program and the requisite knowledge and competency the…

>the language itself may become very complex to permit such a short program

Hit the nail on the head. We can't fight thermodynamics, we can only cheat by drawing lines and pumping entropy one way. "Simplicity" is obtained by hiding complexity away. Modern container ships are reliably run by 13 people because of a huge system of builders and maintainers for everything from diesel engines to navigation systems.

Re: Simple Systems Have Less Downtime (2020)

#170
post #168

Earlier quoted context omitted.

The more I think about it the more it seems to me 'simplicity' is just another name for 'encapsulated/isolated/modularised complexity'

This is only true if all the complexity is necessary and intrinsic to the problem. Simplicity means there is as little incidental (unnecessary) complexity as possible.

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.
Post reply on HN