7 ms·

Thats not how software engineering works in a business setting though? Not a single company I have been in has the time to first fix the existing codebase befor

• huijzer 2y ago
  And then at some point the codebase becomes so unusable that new features take too long and out of frustration management decides to hire 500 extra programmers to fix the situation, which makes the situation even more slow. As I understand, there is a balance between refactoring and adding new features. It’s up to the engineers to find a way to do both. Isn’t it also fair if engineers push sometimes back on management? Shouldn’t a civil engineer speak up if he/she thinks the bridge is going to collapse with the current design?
  • zwnow 2y ago
    The issue is that management usually doesn't care. Personally I usually have about 3-4 days to implement something. If I can't deliver they will just look for more devs, yes. Quantity is what matters for management. New New New is what they want, who cares about the codebase (sarcasm). Management doesn't even know how a good codebase looks. A bridge that is missing support probably wouldn't have been opened to the public in the first place. Thats not correct for codebases.
    • baq 2y ago
      > The issue is that management usually doesn't care. Neither do customers. The product is an asset. Code is a liability.
      • zwnow 2y ago
        Can't be held accountable for work conditions engineers dont have power over. If I dont have time to write tests, I cant be blamed for not writing tests. Especially now with hallucinating bs AI there is a whole load of more output expected from devs.
        • baq 2y ago
          Don't check in any code, only prompts. The product is reconfabulated on every build.
          • xamde 2y ago
            There will be companies founded on executing this idea.
        • strogonoff 2y ago
          Recently I got an email that some severe security defects were found in a project, so I felt compelled to check. A bot called “advanced security AI” by Github raised two concerns in total, both indeed marked as “high severity”: — A minimal 30 LoC devserver function would serve a file from outside the current directory on developer’s machine, if said developer entered a crafty path in the browser. It suggested a fix that would almost double the linecount. — A regex does not handle backslashes when parsing window.location.hostname (note: not pathname), in a function used to detect whether a link is internal (for statically generated site client-side routing purposes). The suggested fix added another regular expression in the mix and generally made that line, already suffering from poor legibility due to involving regular expressions in the first place, significantly more obscure to the human eye. Here’s the fun thing: if I were concerned about my career and job security, I know I would implement every damn fix the bot suggested and would rate it as helpful. Even those that I suspect would hurt the project by making it less legible and more difficult to secure (and by developers spending time on things of secondary importance) while not addressing any actual attack vectors or those that are just wrong. Security is no laughing matter, and who would want to risk looking careless about it in this age? Why would my manager believe that I, an ordinary engineer, know (or can learn) more about security than Github’s, Microsoft’s most sophisticated intelligence (for which the company pays, presumably, some good money)? Would I even believe that myself? If all I wanted was to keep my job another year by showing increased output thanks to all the ML products purchased by the company, would I object to free code (especially if it is buggy)?
    • staunton 2y ago
      > A bridge that is missing support probably wouldn't have been opened to the public in the first place. That's not always been the case and came to be because people have died... Is anyone going to die if your codebase is an unmaintainable mess?
      • hinkley 2y ago
        Companies die because nobody is willing to work on the code anymore. If VCs ever came to expect less than 90% of their investments to essentially go to zero, maybe that would change. But they make enough money off of dumb luck not leading to fatal irreversible decisions often enough to keep them fat and happy.
        • throwaway2037 2y ago
          > Companies die because nobody is willing to work on the code anymore. Can you name some examples? I never heard of this before.
        • staunton 2y ago
          That doesn't sound nearly as bad or serious as people dying.
          • hinkley 2y ago
            One: Have you ever tried to take a narcissists' money or power away from them? You would think you were committing murder (and some of them will do so to 'defend' themselves) Two: All the stuff we aren't working on because we're working on stupid shit in painful ways is substantial.
    • hinkley 2y ago
      That’s why consistent messaging matters. If everyone agrees to make features take as long as they take, then management can’t shop things around. Which they shouldn’t be doing but we all know That Guy. When children do this it’s called Bidding. It’s supposed to be a developmental phase you train them out of. If Mom says no the answer is no. Asking Dad after Mom said no is a good way to get grounded.
    • necovek 2y ago
      It depends. Most shacks built in one's backyard do not pass any building codes. Or throwing a wooden plank over a stream somewhere. Just like most software doesn't really risk anyone's life: the fact that your web site might go down for a bit is not at all like a bridge collapsing. Companies do care about long term maintenance costs, and I've mostly been at companies really stressing over some quality metrics (1-2 code reviews per change, obligatory test coverage for any new code, small, iterative changes, CI & CD...), but admittedly, they have all been software shops (IOW, management understood software too).
  • mrkeen 2y ago
    > As I understand, there is a balance between refactoring and adding new features. True, but has drifted from the TFA's assertion about consistency. As the thread has implied, it's already hard enough to find time to make small improvements. But once you do, get ready for them to be rejected in PR for nebulous "consistency" reasons.
  • danjac 2y ago
    Often the problem with companies running the Feature Factory production treadmill too long is you have code supporting unused features and business logic, but nobody knows any more which features can be dropped or simplified (particularly after lots of employee churn and lack of documentation). So the problem is not so much technical debt, but product debt. You can refactor, but you're also wasting time optimizing code you don't need. A better approach is to sit down with rest of the company and start cutting away the bloat, and then refactor what's left.
    • bluGill 2y ago
      I was involved with a big rewrite. Our manager had on his desk the old system with a sign "[managers name]'s product owner". Nearly every time someone wanted to know how to do something the answer was load that old thing up and figure out what it did. Eventually we did retire the old system - while the new code base is much cleaner I'm convinced it would have been cheaper to just clean that code up in place. It still wouldn't be as clean as the current is - but the current as been around long enough to get some cruft of its own. Much of the old cruft was in places nobody really touched anymore anyway so there was no reason to care.
      • danjac 2y ago
        Whether you rewrite or refactor the code is not so much the point of my comment - it's more that you should first determine what you actually need, in consultation with the project stakeholders, get rid of whatever you don't need, and then you can decide whether you need to rewrite or refactor. Cutting away the bloat will give you a better perspective on that decision. Personally, I would lean towards refactoring - a rewrite is the "declare bankrupcy" stage of technical debt and should only be considered in extremis. For example, the original codebase was written in ColdFusion and in 2025 you can't find any ColdFusion developers (or anyone in their right mind who wants to become a ColdFusion developer). But in any case, rewriting a trimmed down codebase is easier than trying to replicate features you don't need any more.
      • david-gpu 2y ago
        > while the new code base is much cleaner I'm convinced it would have been cheaper to just clean that code up in place I saw one big rewrite from scratch. It was a multi-year disaster, but ended up working. I was also told about an earlier big rewrite of a similar codebase which was a multi-year disaster that was eventually thrown away completely. I did see one big rewrite that was successful, but in this case the new codebase very intentionally only supported a small subset of the original feature set, which wasn't huge to begin with. All of this to say that I agree with you: starting from scratch is often tempting, but rarely smooth. If refactoring in place sounds challenging, you need to internalize that a full rewrite will be a few times harder, even if it doesn't look that way.
  • hinkley 2y ago
    Or it becomes so unusable that the customers become disenchanted and flee to competitors. If management keeps making up deadlines without engineering input, then they get to apologize to the customer for being wrong. Being an adult means taking responsibility for your own actions. I can’t make a liar look good in perpetuity and it’s better to be a little wrong now than to hit the cliff and go from being on time to six months late practically overnight.
• bcrosby95 2y ago
  New features are the right time to refactor. If you can't make the code not complete shit you don't have time to add the feature. Never refactor code to make it prettier or whatever, refactor it when it becomes not-fit-for-purpose for what you need to do. There's obviously exceptions (both ways) but those are exceptions not rules. At least, that's what I teach our devs.
  • zwnow 2y ago
    My company didn't even have time to keep the dependencies up to date so now we are stuck with Laravel 5 and Vue 2. Refactoring/Updating can be an incredible workload. Personally I'd say rewriting the whole thing would be more efficient but that's not my choice to make. If you have plenty of time for a task, I fully agree with you.
    • deleted 2y ago
      [deleted]
    • deleted 2y ago
      [deleted]
    • physicsguy 2y ago
      It's still also often the right business choice, especially for small businesses which aren't making a profit yet.
    • cess11 2y ago
      I was in an organisation that made decent money on a system built on Laravel 3, I think. The framework was written in an only static classes style, which they over ten years had run with while building the business so everything was static classes. Once you have a couple of million lines of that, rewrite is practically impossible because you need to take the team of two OK devs and a junior off firefighting and feature development for years and that will hurt reputation and cashflow badly. My compromise was to start editing Laravel and implementing optimisations and caching, cutting half a second on every request within a month of starting, and then rewriting crude DIY arithmetic on UNIX epoch into standard library date/time/period functions and similar adjustments. I very openly pushed that we should delete at least two hundred thousand lines over a year which was received pretty poorly by management. When I left in anger due to a googler on the board fucking up the organisation with their annoying vision where this monster was to become "Cloud Native" on GCP credits he had, a plan as bad as a full rewrite, it only took a few months until someone finally convinced them to go through with deletions and cut LoC in half in about six months. I don't think they do containers or automatic tests yet, probably never will, but as of yet the business survives.
• hansvm 2y ago
  They don't think they have the time, but that's because they view task completions as purely additive. Imagine you're working on this or that feature, and find a stumbling block in the legacy codebase (e.g., a poorly thought out error handling strategy causing your small feature to have ripple effects you have to handle everywhere). IME, it's literally cheaper to fix the stumbling block and then implement the feature, especially when you factor in debugging down the line once some aspect of the kludgy alternative rears its ugly head. You're touching ten thousand lines of code anyway; you might as well choose do it as a one-off cost instead of every time you have to modify that part of the system. That's triply true if you get to delete a bunch of code in the process. The whole "problem" is that there exists code with undesirable properties, and if you can remove that problem then velocity will improve substantially. Just do it Ship of Theseus style, fixing the thing that would make your life easier before you build each feature. Time-accounting-wise, the business will just see you shipping features at the target rate, and your coworkers (and ideally a technical manager) will see the long-term value of your contributions.
  • zwnow 2y ago
    I am a solo dev for my company which is a semi profitable startup. Before I was hired the codebase was built by a hobbyist and remote workers. I was hired due to a language barrier with the remote staff. I barely have 4 years of experience so I really really dont have the time to fix shit. Currently I have to ship reckless without looking back. Thats upcoming tech companies for ya, will get worse with AI.
    • niels_bom 2y ago
      Expecting a developer with 4 YoE to be able to handle a messy legacy codebase by themselves is a suboptimal business decision I’d say.
    • throwaway2037 2y ago
      > I barely have 4 years of experience so I really really dont have the time to fix shit. I am confused. In my first few years of my career, I did lots of refactoring because it helped me to learn different codebases and learn the skill of refactoring. Your experience is somewhat unrelated to your ability to fix old code. Desire is required.
• cwalv 2y ago
  > I'd love to work in a fantasy company that allows for fixing legacy code You're not supposed to ask. It's like a structural engineer asking if it's okay to spend time doing a geological survey; it's not optional. Or a CFO asking if it's okay to pay down high interest debt. If you're the 'engineer', you decide the extent it's necessary
  • whatevaa 2y ago
    Totally no. Structural engineers also have to consider real life constraints, including cost. We are talking about working with existing structures, it's too late for geological surveys.
    • tremon 2y ago
      That totally depends on the surrounding configuration. If land subsidence was as common as security patches, they would totally be doing monthly surveys. Structural engineers also don't commonly change structural features after initial delivery; realistically, I would expect changing a two-lane bridge to a four-lane bridge to be more expensive than constructing a four-lane bridge where none exists.
  • tomohawk 2y ago
    It's why Scotty was always giving longer estimates that Kirk wanted, but Kirk was also able to require an emergency fix to save the ship. The estimate was building in the time to get it done without breaking too much other stuff. For emergency things, Scotty would be dealing with that after the emergency. If your captain is always requiring everything be done as an emergency with no recovery time, you've got bigger problems.
    • rusk 2y ago
      Scotty manages his tech debt
      • DaiPlusPlus 2y ago
        Scotty is a fictional character.