4 ms·
There's No Limit to How Bad Code Can Get
- cebert 27d agoIf you have ever worked with low-cost offshore contractors, you know this it true…
- sdcfgy 27d agoSo true. I worked one place where I had a team of 4 offshore devs replace my two good people. Three months of some of the worst quality work I’ve ever seen. And I was responsible for it on paper. Decided fuck it, promoted one of them to manager and gave him a project to finish in 3 months, leading the other 3. In that three months I redid that entire project, did their current project and a week of another one. All in a 25 hour week calendar. Then I quit.
- bigstrat2003 27d agoA lot of people are going to get a painful lesson in this if companies keep using LLMs to do all their programming.
- add-sub-mul-div 27d agoMaintaining AI code is the new maintaining offshore code. I don't envy software engineers who are far from retirement.
- nicce 26d agoPeople already look me like crazy when I still review all the code changes AI does, and not even using the agent directly. And make it do things differently if it is unmaintainable slop. Their argument is that are you really going to modify the code by hand in the future?
- teeray 27d ago“Yeah, you’re right, but let’s do that refactor in a separate PR” and it never happens
- jdw64 27d agoThe 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.
- sdcfgy 27d agoLast place I worked they had an ASP.Net MVC controller with basically the entire product in it. The .cs file was nearly 2 megs.
- jdw64 27d agoI've had a very similar experience. Ironically, simple frameworks like WinForms, or tools that promise easy and rapid development, often turn into the absolute worst-case scenarios for maintenance. This tendency is especially strong in code-behind frameworks. Because the domain logic directly relies on the state of UI controls, the business logic becomes entirely entangled with the view itself. And what is the result? Every single architectural layer ends up stuffed inside a specific event handler. I could understand if this came from a small outsourcing shop, but what baffled me was that this was the codebase of the top company in the world in that specific domain. And to top it off, you sometimes have to integrate with an SDK where the methods are literally named function1, function2, and so on. It is always a thrilling experience.
- ChrisMarshallNY 27d agoOne 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.
- gspr 27d ago> 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. And how do you know that the documentation is correct? Because if it's not, it's worse than being absent. The verification work sounds close to as hard as writing it in the first place. This is what I never grasp when people suggest LLMs for anything precise (outside of cases where the LLM output is in a machine-verifiable language).
- pjm331 27d agoThis has been a nice thing about using doctests in elixir. doc examples are compiled and run so they can’t drift. The prose around the examples can still drift of course
- bob1029 27d agoI've seen "clean" codebases that conform to "best practices" which are even less decipherable than what you describe. 100KLoC sounds like paradise compared to the latest codebase I touched. Having the signal to noise ratio fluctuate wildly at every member & file is highly distracting. When the information is dense and consistent, you can drop into a flow state more easily. Four character variable names might sound awful but they can have an advantage. It's a form of compression once you are adapted to it. It forces you to keep things simple. When we can write an entire novel for a variable name, we may be tempted to inflate the scope of a solution. No comments is universally a feature. If I want justification for a section of code, I am going to check git blame, PRs, linked issues, email, project management system, etc. The only code comments I value less than those written by humans are those written by LLMs. It is beyond pointless to shit up a codebase with this stuff. You could just ask the LLM to give you a live interpretation of the current state of the code instead of risking something falling out of sync.
- socalgal2 27d ago2 things 1. 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.
- edukite 27d agoYou are the very first person I encountered who claim LLM can fix technical debt. Usually I seem comments and articles saying LLM can only produce it. And I can agree with those articles and comments
- backlava12 27d ago[dead]
- 27d ago
- felixpg13 27d ago[flagged]
- mrobot 27d agoi'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
- hombre_fatal 27d agoThis 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.
- MartinodF 27d agoWhile I agree and I have done more than one rewrite / cleanup of messy codebases quite successfully with LLMs in the past few months, I can assure you plenty of people are still using the latest models to accrue technical debt faster than I thought was ever possible. The model "taste", assuming it has one, does not survive bad instructions
- gdulli 27d agoPeople refuse to accept that there's more bad code/behavior/people that AI will empower and amplify than good.
- hombre_fatal 27d agoBecause we have evidence otherwise, and even the worst code can be refactored by LLMs. That a high velocity project might accumulate technical debt isn't interesting to me if LLMs can also pay it back or if you can decide to work at a different pace where you polish the architecture as you go instead of accumulating debt. I'd make the opposite claim to you: people really don't want my claims to be true, probably because it robs us of our value and expertise as software engineers. But it's getting a bit late in the game to still be dancing around that pill to swallow.
- efficax 27d agothe models have gotten very good at doing what you ask. if you ask for changes that will accrue tech debt, you'll get it. if you ask for changes that pay down that debt, you'll get it.
- adolph 27d agoYet, 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/d48b84db1ac5d737715e8319bd4dd368 https://gist.github.com/kislayverma/d48b84db1ac5d737715e8319... 1. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- meerita 27d agoThe 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.
- chrismorgan 27d agoIf it only took 59 minutes to process millions of records, it was nowhere near as bad as it could have been. At around one millisecond per record, it sounds like you probably don’t even have any accidental quadratic time complexity on the number of records! What are you complaining about?
- boguscoder 27d agoThe 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
- theanonymousone 27d agoWell, the "limit" is disassembled/obfuscated code, isn't it?
- blevinstein 27d ago> Technical debt has no bankruptcy, no clean reset There 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.
- zkehs 27d agoYes, a rewrite or replacement is the software analogue of the debt metaphor. Section 3 of the article elaborates more on the technical debt statement in the TL;DR, but the gist of the argument there is that for a lot of systems, the rewrite is not really an option. Pretending it is an option is a partial contributor to the attitudes that make the debt spiral (or so I argue). Yes, sometimes a rewrite is possible but the success stories are uncommon and are far outnumbered by failures.
- pir8life4me 27d agoI 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.
- linuxrebe1 27d agoAs 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.
- linuxrebe1 27d agoOh and by the way, I will also submit that there is a form of bankruptcy for technical debt. The company folds, or the software is no longer maintained or in use. When was the last time you used word Perfect? Or MS-DOS?
- lukasgelbmann 27d agoInsightful article. The author makes some great points about the dynamics of technical debt in organizations. I think a sinking ship is a reasonably good metaphor though. A sunken ship is a horrible, terrible outcome. In the metaphor, a codebase is sunken when it’s unviable to continue using it. The organization stops working on it and no longer runs it. At this point, the code is completely worthless to the business, like a ship at the bottom of the ocean. True, you could imagine the code getting worse theoretically. But in reality, it will just sit there and rot.[0] The business might attempt a rewrite or just discontinue the product. It’s possible, but not a given, that a business sinks with one of its codebases. This can happen with a ship too, if a business relies heavily on it. [0] https://en.wikipedia.org/wiki/Software_rot https://en.wikipedia.org/wiki/Software_rot
- jeberle 27d agoRemoving complexity is 2 to +infinity times harder than adding it in the first place.
- Gurio 26d ago[flagged]