3 ms·

> There are a lot of workplaces where there isn’t a good mechanism to push back on this and the tech debt just keeps growing. If the "big ball of spaghetti" th

> There are a lot of workplaces where there isn’t a good mechanism to push back on this and the tech debt just keeps growing. If the "big ball of spaghetti" theory holds, where software companies who can't manage the debt stumble over themselves as they continue to add to the big ball of spaghetti code, I guess we'll see a row of companies declaring "software bankruptcy" or something in some/many months, depending on how well these workspaces learn to care slightly more and get better at pushing back against slop.

codemog 4mo ago
Coding agents have been better than the average "enterprise" programmer for a while now and nobody wants to admit it or talk about it. I have never seen an agent output an implementation called FooImpl that's tens of thousands of LOC in a single file, but I have seen plenty of human code like this. People call coding agents bad because they don't know the asinine meaningless conventions at their particular company while they themselves write awful abstractions and brittle tightly coupled systems, but hey, at least they know how to write a for loop how their particular company likes.
- fzeroracer 4mo ago
  > I have never seen an agent output an implementation called FooImpl that's tens of thousands of LOC in a single file, but I have seen plenty of human code like this. And how long does it take a coding agent to output a thousand lines of code versus a human? The worst human at any company was rate limited by themselves. Those 'average enterprise' programmers aren't going away, they're the ones now spending tens of thousands on coding agents and filling your codebase with even more garbage without bothering to review an iota of it.
  - mkozlows 4mo ago
    Which is why one of the big problems for the field right now is that a) most code bases still need someone more skilled than a mere robot driver, and b) many developers are not better than that. In the past, a team of five mid devs and one good one would be fine, because that good one would ride herd on the mid ones. But now those mid ones are slamming out robot code that they're incapable of meaningfully reviewing (because it's better than they are already), and they're just overwhelming the good dev's capacity. The solution, of course, is to fire them all -- they're worthless now -- but this is not going to happen quickly, and it's probably for the best that it doesn't.
  - ben_w 4mo ago
    > And how long does it take a coding agent to output a thousand lines of code versus a human? Sometimes the human is faster. I've seen someone duplicate a class file (already filled with duplicate methods) rather than subclassing, and when called out on this it was because properties were private. This was a team with just me and him in it, it didn't even really benefit from things being private. That said, the really important lesson I've learned over the years is that terrible code and practices are almost irrelevant: this app won awards and was highly regarded.
- what 4mo ago
  > that's tens of thousands of LOC in a single file Why is this worse than splitting it across 1k files?
  - codemog 4mo ago
    Does taking this example and extending it to the limit answer your question? There is a reason we don’t have a single file called program with a million lines of code in it. Google studies on module size vs code defect rates for more empirical numbers.
    - ben_w 4mo ago
      The limit you're replying to is files which are each tens of lines long. At that point, the cognitive overhead of switching documents is larger than the benefit of a compact object to reason about. (Personally my threshold is around 2-5 thousand lines per file depending on what it is; but that's me working solo, obviously I'll follow whatever standards any team I'm in gives me).
- jeppester 4mo ago
  Yesterday Claude wanted to add a position column to what is a slightly extended many-many relation table. It did this to "make ordering stable". An average enterprise developer would never add bloat like that up-front, unless if the ability to change the order was a requirement. Obviously a stable order can be easily derived from the ID or a creation time (if available). Setting a position however requires extra steps to ensure the integrity of the sequence. I see things like that all the time, and it's always stuff that grows the code base and adds unnecessary complexity.
- kuschku 4mo ago
  > I have never seen an agent output an implementation called FooImpl that's tens of thousands of LOC in a single file, but I have seen plenty of human code like this. I've seen countless vibecoded implementations that look exactly like that. Especially painful is agents adding the same utility functions in each and every file instead of properly reusing or splitting things. And then I have to fix them.
- andrekandre 4mo ago
  no i've never seen even a junior do something as crazy as displaying a page sheet ui from literally a color object, yes, a literal color...
aryehof 4mo ago
What concerns me the most is that improvements in software design are at an end. The “big ball of mud”, which really is a problem of modularity and dependencies, will never improve through innovation because the way it is done now is all there will ever be.
onion2k 4mo ago
I guess we'll see a row of companies declaring "software bankruptcy" or something in some/many months I don't think you will, because that would require the business to recognise the problem. That might happen in companies where the leadership team are engineers but it will never happen if they're not. Instead you'll see: - Churn in the dev team with senior developers leaving rather than try to deal with the mess - Large scale projects to refactor or rewrite entire codebases, which will inevitably fail because you can't rewrite a big ball of spaghetti because you can't tell what it actually does (especially if it's in a language that allows side effects, or you've used a strategy like 'exceptions as flow of control'). - Companies just getting slower and slower to deliver anything. That's probably fine in many cases where they're big enough to still carry on without growing much, but anyone in the company will see their career die and pay rises dry up. - Eventually, maybe, you'll see 'tech debt fixing' service companies start up to leverage AI in the effort to fix these problems. (AWS have a thing called 'Amazon Modernization Lab' that is exactly that, but only for companies running old tech on their services.)
danaris 4mo ago
The problem is that this is just another instance of trusting that "the market will solve all our problems." But that's based on "spherical economy in a frictionless vacuum" type assumptions. In the real world, in addition to the problems others have noted of it being hard to identify and fix the specific sources of problems, we have so much consolidation that it doesn't matter if something from any of the tech giants starts getting buggier and slower. What are you* going to do—switch from Windows to Linux, just because it's getting a bit buggy? Or worse, switch away from Banner, or Salesforce? We cannot depend on "market forces" to prove whether LLM-assisted coding is actually a good idea. We have to push for universal personal accountability for the code we commit (at least internally; I'm not calling for legal liability here!). Which is, unquestionably, going to be a huge uphill slog. * where "you" in this case is an average PC user, or a large institution

codemog 4mo ago

Coding agents have been better than the average "enterprise" programmer for a while now and nobody wants to admit it or talk about it. I have never seen an agent output an implementation called FooImpl that's tens of thousands of LOC in a single file, but I have seen plenty of human code like this. People call coding agents bad because they don't know the asinine meaningless conventions at their particular company while they themselves write awful abstractions and brittle tightly coupled systems, but hey, at least they know how to write a for loop how their particular company likes.

fzeroracer 4mo ago
> I have never seen an agent output an implementation called FooImpl that's tens of thousands of LOC in a single file, but I have seen plenty of human code like this. And how long does it take a coding agent to output a thousand lines of code versus a human? The worst human at any company was rate limited by themselves. Those 'average enterprise' programmers aren't going away, they're the ones now spending tens of thousands on coding agents and filling your codebase with even more garbage without bothering to review an iota of it.
- mkozlows 4mo ago
  Which is why one of the big problems for the field right now is that a) most code bases still need someone more skilled than a mere robot driver, and b) many developers are not better than that. In the past, a team of five mid devs and one good one would be fine, because that good one would ride herd on the mid ones. But now those mid ones are slamming out robot code that they're incapable of meaningfully reviewing (because it's better than they are already), and they're just overwhelming the good dev's capacity. The solution, of course, is to fire them all -- they're worthless now -- but this is not going to happen quickly, and it's probably for the best that it doesn't.
- ben_w 4mo ago
  > And how long does it take a coding agent to output a thousand lines of code versus a human? Sometimes the human is faster. I've seen someone duplicate a class file (already filled with duplicate methods) rather than subclassing, and when called out on this it was because properties were private. This was a team with just me and him in it, it didn't even really benefit from things being private. That said, the really important lesson I've learned over the years is that terrible code and practices are almost irrelevant: this app won awards and was highly regarded.
what 4mo ago
> that's tens of thousands of LOC in a single file Why is this worse than splitting it across 1k files?
- codemog 4mo ago
  Does taking this example and extending it to the limit answer your question? There is a reason we don’t have a single file called program with a million lines of code in it. Google studies on module size vs code defect rates for more empirical numbers.
  - ben_w 4mo ago
    The limit you're replying to is files which are each tens of lines long. At that point, the cognitive overhead of switching documents is larger than the benefit of a compact object to reason about. (Personally my threshold is around 2-5 thousand lines per file depending on what it is; but that's me working solo, obviously I'll follow whatever standards any team I'm in gives me).
jeppester 4mo ago
Yesterday Claude wanted to add a position column to what is a slightly extended many-many relation table. It did this to "make ordering stable". An average enterprise developer would never add bloat like that up-front, unless if the ability to change the order was a requirement. Obviously a stable order can be easily derived from the ID or a creation time (if available). Setting a position however requires extra steps to ensure the integrity of the sequence. I see things like that all the time, and it's always stuff that grows the code base and adds unnecessary complexity.
kuschku 4mo ago
> I have never seen an agent output an implementation called FooImpl that's tens of thousands of LOC in a single file, but I have seen plenty of human code like this. I've seen countless vibecoded implementations that look exactly like that. Especially painful is agents adding the same utility functions in each and every file instead of properly reusing or splitting things. And then I have to fix them.
andrekandre 4mo ago
no i've never seen even a junior do something as crazy as displaying a page sheet ui from literally a color object, yes, a literal color...

aryehof 4mo ago

What concerns me the most is that improvements in software design are at an end. The “big ball of mud”, which really is a problem of modularity and dependencies, will never improve through innovation because the way it is done now is all there will ever be.

onion2k 4mo ago

I guess we'll see a row of companies declaring "software bankruptcy" or something in some/many months I don't think you will, because that would require the business to recognise the problem. That might happen in companies where the leadership team are engineers but it will never happen if they're not. Instead you'll see: - Churn in the dev team with senior developers leaving rather than try to deal with the mess - Large scale projects to refactor or rewrite entire codebases, which will inevitably fail because you can't rewrite a big ball of spaghetti because you can't tell what it actually does (especially if it's in a language that allows side effects, or you've used a strategy like 'exceptions as flow of control'). - Companies just getting slower and slower to deliver anything. That's probably fine in many cases where they're big enough to still carry on without growing much, but anyone in the company will see their career die and pay rises dry up. - Eventually, maybe, you'll see 'tech debt fixing' service companies start up to leverage AI in the effort to fix these problems. (AWS have a thing called 'Amazon Modernization Lab' that is exactly that, but only for companies running old tech on their services.)

danaris 4mo ago

The problem is that this is just another instance of trusting that "the market will solve all our problems." But that's based on "spherical economy in a frictionless vacuum" type assumptions. In the real world, in addition to the problems others have noted of it being hard to identify and fix the specific sources of problems, we have so much consolidation that it doesn't matter if something from any of the tech giants starts getting buggier and slower. What are you* going to do—switch from Windows to Linux, just because it's getting a bit buggy? Or worse, switch away from Banner, or Salesforce? We cannot depend on "market forces" to prove whether LLM-assisted coding is actually a good idea. We have to push for universal personal accountability for the code we commit (at least internally; I'm not calling for legal liability here!). Which is, unquestionably, going to be a huge uphill slog. * where "you" in this case is an average PC user, or a large institution