Hacker News
points by eithed 3 days ago | 0 comments
Agree. It should fall on to developers to decide what to do = whether tackling tech debt is viable solution (whether making decision on their own or talking to people that can make such decision) or not. If, however, you're told "here is a codebase that you're seeing for first time, fix this error" and you simply cannot make the decision, even prior to LLMs you'd put a bandaid on it. Or at least - that's the standard approach = fix now, refactor later, where later in my experience never happens (sorry for this train of thought).

I don't think this is anything new, nor LLMs are to blame here. Although - LLMs want to make you happy, or maybe they don't think about what user actually needs, just how to accomplish the goal that was stated; they do stuff without asking questions (unless you constrain them or plan first). I've actively put in a hook for my agent to not make decisions on their own and ask me when it detects it's about to make a decision.

[–] bunderbunder 3 days ago
Agreed, it is not at all a new problem. The enterprisey codebases I’ve encountered are ones that have chronically had no clear owner, or constant ownership churn. I have been in that position before, and I also decided to make the code even more bloated for the same reason: I did not and was not going to have the time to learn the system well enough to safely do a better job.

I think where a lot of people run into problems with the KISS principle is they conflate simple and easy. More often than not, simple is hard. Which is maybe a soft reason why agentic coding, which is all about trying to make every task easy, leads so consistently to complexity and bloat.

[–] rmunn 2 days ago
Nobody else is likely to see this comment but I want to make it anyway. Yes, simple is hard. Thank you for articulating it so well.

And yes, that's also why LLM code is usually (unless driven by someone who really knows what he's doing) full of unnecessary complexity. Because although LLMs can get a much broader "understanding" of a code base than I would have given them credit for a couple years ago, their "understanding" is still shallow. And what you need to truly be able to achieve that hard simplicity (I heard someone refer to it once as "the simplicity on the other side of complexity", e.g. when Kepler figured out that orbits were ellipses, not circles, and that allowed getting rid of epicycles) is deep understanding. Which LLMs are not capable of, hence why their code is full of the kind of needless complexity that one produces when one has only a shallow understanding of the code. (E.g., you in that enterprisey codebase when you weren't going to be given time to reach deep understanding).

[–] eithed 2 days ago
I don't think I agree that simple is hard. Simple takes effort. Simple requires that you have agency. Simple has all the information available. Simple means that you're accountable for something. I'll be cynical here - it's sooooo much easier to say: this is how it was when I arrived here, it's not my problem, what will I get out of this, somebody told me to do it like this, let's leave as it is, there's no point in touching this. And nothing in the above is LLMs fault! Well, unless at least now you can say - something did it like that! It's not my fault, it's what LLM told me to do.

I'm hopeful that LLMs make iteration and refactoring easier. That they'll allow developers to say to product (or even to themselves) "this module that is a dumpster fire? Sure, I can let agent investigate/refactor and that work that would have taken 2w will be done in half a day, do you want to go ahead?". That they'll allow developers to investigate how to make things simpler, more understandable, more coherent, to agree on a one fucking way to do things.

Anyhow, apologies for being glum and straying away from the topic, but I also wanted to make a comment that is unlikely to be seen :) the bile comes from past personal experience and is not directed towards anyone (it's more of an acid reflux).

[–] rmunn 2 days ago
When you say "simple takes effort", that's kind of what I meant by "simple is hard". It takes work, it takes looking at the problem for a long time (Kepler studied orbits for years) until you understand it well enough to have the epiphany that lets you reduce the complexity down to "oh wait, orbits are ellipses and that solves everything!". Since you preceded your statement that "simple takes effort" with a disagreement about simple being hard, I wonder what you thought I meant by "simple is hard".