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

Nobody gets promoted for simplicity

terriblesoftware.org

Post reply on HN
Print view View original

11–20 of 95 posts

Re: Nobody gets promoted for simplicity

#11

Post by pinkmuffinere »

ChadMoran wrote: post #8

I launched a technical feature on Amazon's retail platform that is responsible for 9 figures worth of revenue. When I launched it, it had no infrastructure. It was a collection of small changes across every core platform (Detail Page, Cart, Checkout, etc). At first people were like "Well, you didn't do much" but when they saw the value things changed drastically. It's a bit of marketing you have to do to help bring p…

Coincidentally similar story, but with a different end -- I eliminated a test station from the final assembly line for Astro (Amazon's home robot), because there were no unique failure modes that the test station could catch (we collected ideas, and then went through and analyzed every failure mode suggested, they would all be detected by other stations). I think we estimated that was ~$1 million savings, in addition to simplifying the workflow and reducing time spent to do final testing. I brought this up with my manager when pushing for a promo, but he told me "somebody else made that value, you just stopped it from being thrown away", lol. Maybe I should have pushed harder, but I definitely felt underappreciated, and am still not sure if I could have gotten better recognition for it.

Don't feel sorry for me though, they still paid me well enough, and I'm happily doing my own stuff now :)

Re: Nobody gets promoted for simplicity

#12

Post by Duanemclemore »

Great article. Where my mind goes as a counterpoint that proves the point is the famous Bill Atkinson lore about -2000 lines of code[0].

As a practicing architect (of buildings) I had a special fondness of working on minimalist projects. Buildings are a complex problem space. You typically can't design out unnecessary complexity entirely. So you have to work backward from goals (the finished condition) to infrastructure (the building structure) to figure out how to make the end product look like almost nothing (Mies's "beinahe nichts").

That's all to say that "complexity impresses" as the article says, but the discerning understand that simplicity can be even more impressive.

It also puts me in the frame of mind of another famous one - Fred Brooks's "No Silver Bullet" [1] and the idea of essential vs. accidental complexity. Or as I like to think of it in a slightly more nuanced way - not necessarily "accidental" but at least "incidental."

[0] https://www.folklore.org/Negative_2000_Lines_Of_Code.html

[1] https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...

Re: Nobody gets promoted for simplicity

#13

Post by bruce511 »

jamesfinlayson wrote: post #9
danpalmer wrote: post #3

In my experience this doesn't happen as often as some people like to state. It tends to be less experienced, more junior, engineers that propose complex solutions, and more experienced engineers are the ones driving simplicity – both because they've been burned by complexity and value the simplicity more, and because they have the experience to clarify and distil problems down enough to get to the simplest solutions.…

I haven't worked at that many companies to have an informed opinion, but I've certainly been at a couple of places where smart people went along with ridiculous complexity, but part of the reason was there was already a hugely complicated mess with way too many people working on it for a simple solution to be politically feasible.

While the post seems simple, it's arguably complex, as the comments here point out.

Simple solutions are good enough some of the time, perhaps even most of the time, but often fall down with edge cases. But edge cases add up, and dealing with them is complicated.

For example, calculating pay for hourly paid workers is a "simple" problem. Deduct start time from end time and multiply by rate. Covers 90% of the workforce.

But the other 10% take much more work. That team that rotates an on-call worker (which earms an allowance), who gets a call (first hour is free, next is double time etc.)

So it is with software. Adding 2 numbers is trivial. But what about overflows? What about underflows? What if one number is infinity? What if it's i?

The simple solution is "just add, ignore edge cases". The complex solution handles the edge cases. Which is better in the long run?

Re: Nobody gets promoted for simplicity

#14

Post by danpalmer »

jamesfinlayson wrote: post #9
danpalmer wrote: post #3

In my experience this doesn't happen as often as some people like to state. It tends to be less experienced, more junior, engineers that propose complex solutions, and more experienced engineers are the ones driving simplicity – both because they've been burned by complexity and value the simplicity more, and because they have the experience to clarify and distil problems down enough to get to the simplest solutions.…

I haven't worked at that many companies to have an informed opinion, but I've certainly been at a couple of places where smart people went along with ridiculous complexity, but part of the reason was there was already a hugely complicated mess with way too many people working on it for a simple solution to be politically feasible.

This is true, I think there's also quite a lot of folks sticking their head in the sand about complexity. Software should be as simple as possible _but no simpler_, yet I see a lot of people floating "simple" solutions that don't actually meet the requirements. By all means be skeptical of requirements, but disregarding them without any work to remove them, is just bad engineering.

Re: Nobody gets promoted for simplicity

#15

Post by jtbaker »

ChadMoran wrote: post #8

I launched a technical feature on Amazon's retail platform that is responsible for 9 figures worth of revenue. When I launched it, it had no infrastructure. It was a collection of small changes across every core platform (Detail Page, Cart, Checkout, etc). At first people were like "Well, you didn't do much" but when they saw the value things changed drastically. It's a bit of marketing you have to do to help bring p…

How do you ascribe a revenue number like that based on one collection of changes in a huge system? Presumably there were a bunch of other features being released around the same time as it. Was there a lot of A/B testing around it?

Re: Nobody gets promoted for simplicity

#16

Post by nixon_why69 »

bruce511 wrote: post #13
jamesfinlayson wrote: post #9

Earlier quoted context omitted.

I haven't worked at that many companies to have an informed opinion, but I've certainly been at a couple of places where smart people went along with ridiculous complexity, but part of the reason was there was already a hugely complicated mess with way too many people working on it for a simple solution to be politically feasible.

While the post seems simple, it's arguably complex, as the comments here point out. Simple solutions are good enough some of the time, perhaps even most of the time, but often fall down with edge cases. But edge cases add up, and dealing with them is complicated. For example, calculating pay for hourly paid workers is a "simple" problem. Deduct start time from end time and multiply by rate. Covers 90% of the workforc…

Essential complexity is a class full of methods to compute your complicated payroll.

Unnecessary complexity is a microservice architecture to do the same thing.

Re: Nobody gets promoted for simplicity

#17

Post by xiphias2 »

This is just not true, people get promoted for delivering impact whether the solution is complex or simple.

The best engineer I know who can work with huge complex systems in a big company usually starts with a complex solution then after he understands what he wants to achieve thinks backwards and reimplements it in the fewest possible lines of code change with the already complex system.

Re: Nobody gets promoted for simplicity

#19

Post by rvz »

danpalmer wrote: post #3

In my experience this doesn't happen as often as some people like to state. It tends to be less experienced, more junior, engineers that propose complex solutions, and more experienced engineers are the ones driving simplicity – both because they've been burned by complexity and value the simplicity more, and because they have the experience to clarify and distil problems down enough to get to the simplest solutions.…

The engineering team at a large bank some time ago did a blog post of having over 4,000+ microservices where a single API call from the client interacts with 1,100 of those microservices. Sounds great a great architechture right? /s

Would you want to be in charge of simplifing this architecture for a 'senior staff' title for 4+ years?

This is just one of many examples who have this sort of complexity and it is celebrated, and the microservices hype (originated from Netflix and overhyped by Thoughtworks) have somewhat caused this madness and for some, it has turned into a mountain of technical debt to maintain.

Unless you have a very good reason to save a company from drowing over it's own complex infrastructure costs to run itself, attempting to simplify this architecture will be met with feroucious backlash by other teams of senior staff engineers, hundreds of meetings with risk officers and being blocked because of forever meetings with architects.

Re: Nobody gets promoted for simplicity

#20

Post by losalah »

This hit a nerve because “simplicity” is one of those things you only notice when it’s missing, and most orgs don’t have a good way to reward “the thing that didn’t happen.”

I’ve watched this exact dynamic play out: one person ships the boring implementation, nothing breaks, everyone moves on. Another person ships the “platform” version, there are docs, diagrams, an internal talk… and now there’s a subsystem that needs to be explained to every new hire. Guess which one looks like “impact” on paper.

The part I think is under-discussed is that complexity has a carrying cost that rarely gets charged to the builder. The team pays it later: more surface area, more failure modes, more time spent reading before changing. In that sense, unearned complexity is like taking on leverage. Sometimes it’s the right move, but you should need a business case, not just enthusiasm.

What’s helped on teams I’ve liked: make “simplicity” legible by treating it as a decision record. In the PR/ADR, explicitly list the two “cooler” options you didn’t take and why, and write down the trigger conditions for upgrading later (“if p95 > X for Y days”, “if we add a second producer”, etc.). That turns “implemented feature X” into “made a deliberate tradeoff, reduced risk, and defined a clear escape hatch.” It also forces the room to argue with specifics rather than vibes like “future-proofing.”

Also +1 on the interview point. A lot of system design interviews are accidentally training people that the goal is to draw more boxes until the interviewer nods. The more senior move is usually: start simple, instrument, set thresholds, and only then add machinery. But that’s harder to “perform” in 45 minutes than rattling off Kafka and sharding.

If an org wants to fix the incentive, I think the question to ask in reviews isn’t “how big was the thing you built,” it’s “did you make the system easier to change next quarter.” That’s the kind of impact that compounds, and it’s usually correlated with simplicity.

Post reply on HN