HN

Comments (69)

• Menu

  ChrisMarshallNY
  One of my first jobs, was as a maintenance engineer, on a 100KLoC+ codebase of 1979s-era FORTRAN IV.No comments.No subroutines (what we now call “functions”).No variable name longer than 4 characters.Fun. The most effective debug tool, was a Ouija board. It made me an expert WAGger.It was the main reason that I am so anal about code Quality, these days. I never want to subject anyone else to that.BTW: with today’s LLMs, there’s really no excuse for badly-documented, or badly-formatted code. You can write a thousand lines of commercial-grade spaghetti, and tell the LLM to format and document it.
• Menu

  blevinstein
  > Technical debt has no bankruptcy, no clean resetThere definitely is a technical debt bankruptcy option.You can stop using a particular piece of code or technology, e.g. by replacing it (with new code, or a third-party/vendor solution), or re-architecting a system or business process so that the code's function is no longer needed.This is exactly what the technical debt metaphor means. Short-lived systems can accumulate a lot of technical debt without as much concern, because you're planning to declare bankruptcy (deprecate and decommission) the code soon anyways; long-lived systems must plan to pay off their technical debt on the usual installment plan.
• Menu

  socalgal2
  2 things1. LLM can fix this in my experience. an LLM, especially the more modern ones, have way more short term memory than most humans (or at least way more than me). They can dig through this kind of code and figure out all the edge cases, write test, suggest various paths to make things better and then execute on those paths. On request they will happily setup dev systems, staging systems, whatever it takes to make the transition safe. At least that's my experience. They can dig much further than I ever would.2. Short of and maybe separate to the LLM fix, this pattern of technical debt I think is nearly inevitable, at least with humans. In a perfect world, every human and every reviewer knows exactly what architecture to write and what tests to convey all of the rules and assumptions because no matter what, people are going to leave. I've never seen that code base though. So the rules and assumptions are at best half written down, maybe in some comments or docs, comments or docs that the next person to edit that part of the code base may or may not see. And so it goes.I work on a code base that runs on Windows, Mac, Linux, Android, iOS. Those OSes change over time, their requirements change, their APIs change, the world changes and new APIs are needed for new things people do, and our original choices for cross platform solutions, no longer fit perfectly. We need to keep moving and shipping and we can't just stop the world and re-architect. Further, like the OP, not everything is written down and communicating across hundreds of programmers is hard. So yes, not every decision is perfect. It never will be. Fortunately we work to fix these things and pay down our technical debt but it can take 5 to 10 years before we can finally remove some old path while we wait on usage numbers for old OSes to go down far enough that we can remove those paths and switch everyone over to the new. And then the cycle repeats.
• Menu

  cebert
  If you have ever worked with low-cost offshore contractors, you know this it true…
• Menu

  linuxrebe1
  As I read this article, as a non-coder (for a living) I noticed that what is being assumed is that the code produces a desired result. To that I will agree. You can really produce some bad code that has a positive outcome.But as a counter proposal, I will submit that code can get so bad, that the product no longer produces a desirable result, no longer produces it in a manner that people want, or doesn't produce it at all.Code that produces no desirable result or no result at all. Is as bad as it's going to get. It's a worthless pile of ASCII characters.
• pir8life4me
  I recently got a thank you and a refund for towels I had returned from Amazon.The towels were damp from bring used, I had never initiated a refund return, nor had I in fact returned them.I reported this to amazon and had to find a human since the system had no "refund for nonexistent returns" option. The human didn't get it and pinged his team lead. After 20 minutes they told me to just keep my towels and refund.
• Menu

  meerita
  The worst experience I had was with a telecom company. They had an internal web app that allowed them to upload a gigantic CSV file with millions of records from new phone activations. The web app took 59 minutes to process it!The culprit: a single 30K .js file with one function, more and more recursive functions, and deeply nested if/else statements, up to 10 levels.We spent one month undoing that Gordian knot and got the same process down to less than a minute. With AI, we probably would have done it in less than a day, and with a better programming language, probably even faster.
• Menu

  hombre_fatal
  This is a good example of what LLMs save us from.Everyone likes to pretend that LLMs are only capable of writing mudballs, but it's trivially debunked by using LLMs yourself to refactor code, pay back debt, and fan out agents to look for debt to repay.We're already at the point with sota models where I'm not even sure you can get the sort of mudballs OP is talking about; the LLM's inherent "taste" forbids it, and it can just end-to-end refactor as requirements change.The hypermudballs were distinctly a human creation due to how expensive it is to generalize and refactor brittle, incremental production code.
• theanonymousone
  Well, the "limit" is disassembled/obfuscated code, isn't it?
• teeray
  “Yeah, you’re right, but let’s do that refactor in a separate PR” and it never happens
• adolph
  Yet, our organization was hundreds of people, and the system had grown so large and complex that it had become impossible to learn how it all worked. Which is what makes Bezos' service mandate [0] a classic exposition of Conway's Law [1]. All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. 0. https://gist.github.com/kislayverma/d48b84db1ac5d737715e8319...1. https://en.wikipedia.org/wiki/Conway%27s_law
• boguscoder
  The funny thing is that these days they would make it a lot worse with LLMs, perhaps post lots of wins on LinkedIn too. It’s not impossible to steer that ship but it’s never gonna be one shotted in “do refactor, make no mistake” way
• Menu

  jdw64
  The worst I have experienced: A 30,000-line .cs file. A giant monolithic program tangled together by Singleton abuse, 6-deep nested if/else blocks, and the list goes on. There are too many to count. And this is a sight I see every single day. This is the exact landscape I encounter at many companies when I go in for maintenance work. Encapsulation completely shattered as a direct reflection of the subcontracting power hierarchy, among other things...Code that completely disregards collaboration, utilizing outdated algorithms in the name of "optimization" and making it utterly unmaintainable for anyone else.We learn about ADTs, Result-first approaches, Composition Roots, and code hygiene, yet at some point, code that simply "works" becomes what ships to production.Communities advocate for building "good software," but the reality in the field is that most of it is "code written just to clock out for the day." I hear "it works, so don't touch it" in dozens of different variations.The quality of an open-source project contrasts sharply with that of delivered enterprise software. People settle for the "if it works, it's fine" mindset because in open source, the code itself represents personal reputation, whereas in contract deliveries, meeting the deadline is ultimately the core objective...It feels like the world is always polarized.
• felixpg13
  [flagged]
• mrobot
  i've heard the same thing about pain which may be an interesting argument against the resurrection or at least that Jesus died for my sins and not because of them