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

321–330 of 534 posts

Re: Nobody gets promoted for simplicity

#321

Post by matsemann »

sovietswag wrote: post #249
bilsbie wrote: post #73

I had an interview question. What would you do if two different people were emailing a spreadsheet back and forth to track something? I said I’d move them to google sheets. There was about five minutes of awkwardness after that as I was interviewing for software developer. I was supposed to talk about what kind of tool I’d build. I found it kind of eye opening but I’m still not sure what the right lesson to learn was…

Ha! I just had a debate about this with my friend. A certain ferry company uses a big Google Sheet to track where all of its vessels are currently docked in their home port, as well as which employee is assigned to which vessel for the day, etc (it's very information dense with color coding, and employees check it daily to get their vessel assignment). My friend thought this was completely unacceptable for a big comp…

I've just spent a few weeks making a tool in our software to replace a complicated google sheet, and it was surprisingly hard. I think the most important thing was that our designer really figured out what the tool should do. If we've just replicated what they have and made a columnar editor of sorts, we would've just made a less flexible tool for them. But in the end, we made something not even resembling what they had, but which actually solved the core issue, and I think that's important.

And when you take away their sheet, you better be ready to support them. If they need to track new data, they could just add a new column in their sheet. Now they have to talk with tech. If tech blocks operations, they're quickly back to their sheets. The tool made by tech should be an enabler, not something to force compliance or whatever.

Sheets are so, so flexible. This can be really hard to replace. At the same time, they're also brittle with little system support. Like the example above, what if you assign someone not working that day to a boat? Or accidentally put two boats in the same location? Lots of small issues that proper tooling could handle, especially when backed with more data inside the system.

What made the operators happy to use my tool in the end was that they didn't have to punch so many numbers. They would copy paste numbers from various systems into their sheet every hour to keep track. The tooling pulls it in real-time.

So we replaced this one sheet, because it would help them a lot. But their other sheets we're leaving untouched for now. Nothing to gain by moving them. So judge each sheet individually.

Re: Nobody gets promoted for simplicity

#323

Post by e-topy »

praptak wrote: post #53
codingdave wrote: post #2

Sure they do. You just need to spell it out in business terms, not tech terms: "Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by 33% while decreasing server footprint by 25%" Simplicity for its own sake is not valued. The results of simplicity are highly valued.

You can't measure the impact of not creating a steaming pile of complexity.

You can. GitHub is about to hit zero nines of uptime[0]. But feedback like that is far too late to be useful. Maybe (principal or senior) engineers should be the ones to judge, and be trusted by management that their foresight is worth pushing the deadline?

[0]: https://mrshu.github.io/github-statuses/

Re: Nobody gets promoted for simplicity

#324

Post by 1024core »

codingdave wrote: post #2

Sure they do. You just need to spell it out in business terms, not tech terms: "Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by 33% while decreasing server footprint by 25%" Simplicity for its own sake is not valued. The results of simplicity are highly valued.

Except when one of the criteria for promos is "demonstrates complexity". Then you results do matter, but you don't have the "complexity" box checked.

Re: Nobody gets promoted for simplicity

#325

Post by sampo »

jghn wrote: post #223
wongarsu wrote: post #127

Earlier quoted context omitted.

If the point of the interview was to test if the candidate can design something that can handle google-scale problems then maybe the interviewer shouldn't state throughput and availability requirements that can be satisfied by postgres

It's both. As a hiring manager I've had situations like this arise because there was a gap in my plan and I didn't realize it. When those come up, we thank them for their cleverness, apologize to the candidate, reframe the situation, and give them another shot. But also sometimes I leave intentional ambiguity in the plan. Part of the goal is to see if they have a degree of common sense commensurate to their level. If…

> and give them another shot

Isn't this rather giving yourself another shot.

Re: Nobody gets promoted for simplicity

#326

Post by strix_varius »

tracker1 wrote: post #268

I'd add one point to this, as someone who voraciously fights against complexity at every turn, more and more as I get older. I've experienced times where leadership/management will assume that you're fighting against the complex solution simply because you don't grasp or understand it. It's irritating at best. The longest lived projects and solutions I've worked on have always been the simplest, easiest to replace so…

To add to this, sometimes leadership will assume (or even imply) that there's some laziness involved in not wanting to jump immediately on-board with the complex proposal.

I often end up saying, "I can build this, and I will build this if product insists on it, but first let me suggest an alternative ordering of deliverables that starts with a simple implementation and moves towards this one." In almost every case, that simple implementation is still what's in production years later.

Re: Nobody gets promoted for simplicity

#327

Post by muyuu »

slfnflctd wrote: post #129
Niko901ch wrote: post #21

AI coding tools are making this problem worse in a subtle way. When an agent can generate a "scalable event-driven architecture" in 5 minutes, the build cost of complexity drops to near zero. But the maintenance cost doesn't. So now you get Engineer B's output even faster, with even more impressive-sounding abstractions, and the promotion packet writes itself in minutes too. Meanwhile the actual cost - debugging, onb…

> now nobody fully understands what was generated To be fair, a lot of the on call people being pulled in at 3am before LLMs existed didn't understand the systems they were supporting very well, either. This will definitely make it worse, though. I think part of charting a safe career path now involves evaluating how strong any given org's culture of understanding the code and stack is. I definitely do not ever want…

it's MUCH worse now, not just because of the massive amount of code generated with zero supervision or very little supervision, but also because of the speed at which the systems grow in function

Re: Nobody gets promoted for simplicity

#328

Post by zackmorris »

Just about every project I've ever worked on eventually needed everything.

So the way we write software piecemeal today is fundamentally broken. Rather than starting with frameworks and adding individual packages, we should be starting with everything and let the compiler do tree shaking/dead code elimination.

Of course nobody does it that way, so we don't know what we're missing out on. But I can tell you that early in my programming journey, I started with stuff like HyperCard that gave you everything, and I was never more productive than that down the road. Also early C/C++ projects in the 80s and 90s often used a globals.h header that gave you everything so you rarely had to write glue code. Contrast that with today, where nearly everything is just glue code (a REST API is basically a collection of headers).

A good middle ground is to write all necessary scaffolding up front, waterfall style, which is just exactly what the article argues against doing. Because it's 10 times harder to add it to an existing codebase. And 100 times harder to add it once customers start asking for use cases that should have been found during discovery and planning. This is the 1-10-100 rule of the cost of bugs, applied to conceptual flaws in a program's design.

I do miss seeing articles with clarity like this on HN though, even if I slightly disagree with this one's conclusions after working in the field for quite some time.

Re: Nobody gets promoted for simplicity

#329

Post by gondo »

slfnflctd wrote: post #129
Niko901ch wrote: post #21

AI coding tools are making this problem worse in a subtle way. When an agent can generate a "scalable event-driven architecture" in 5 minutes, the build cost of complexity drops to near zero. But the maintenance cost doesn't. So now you get Engineer B's output even faster, with even more impressive-sounding abstractions, and the promotion packet writes itself in minutes too. Meanwhile the actual cost - debugging, onb…

> now nobody fully understands what was generated To be fair, a lot of the on call people being pulled in at 3am before LLMs existed didn't understand the systems they were supporting very well, either. This will definitely make it worse, though. I think part of charting a safe career path now involves evaluating how strong any given org's culture of understanding the code and stack is. I definitely do not ever want…

People on call will use AI as well. As long as the first AI left enough documentation and implemented traceability, the diagnosing AI should have an easier time proposing a fix. Ideally, AI would prepare the PR or rollback plan. In a utopia, AI would execute it and recover the system until a human wakes up.

Or at least there is something to chat with about the issue at 3am.

Re: Nobody gets promoted for simplicity

#330

Post by bluemario »

The structural problem is that simplicity accrues value slowly and diffusely, while complexity delivers visible credit immediately to whoever built it. The person who adds the abstraction layer gets the PR merged and the ticket closed. The person who deletes it six months later gets... a smaller diff and a shrug.

I've noticed the incentive breaks down even further when you consider that simplicity often means saying no upfront, which requires correctly predicting future maintenance costs that nobody has experienced yet. Complexity requires no such foresight. You just build the thing someone asked for.

The orgs where I've seen this actually work had explicit "deleted lines" culture, where removing code was celebrated as loudly as shipping features. Not many places do that. Most treat a 2000-line deletion PR with the same energy as taking out the trash.

Post reply on HN