4 ms·

Interestingly this is also related to employee churn. New devs coming to our company usually don’t want to “maintain and fix” the code of others. They’re keen o

• TheChaplain 7y ago
  Really? I'm quite to opposite, I love to look through old code, add missing testcases and fix minor issues. It helps me greatly to learn the ins and outs of the software.
  • newnewpdro 7y ago
    There's definitely a preference for writing new code vs. maintaining and extending existing code, especially when it isn't even yours. This is a general human nature thing, it's apparent everywhere in life: "It's more attractive to create new problems than address existing ones"
  • collyw 7y ago
    I don't mind if i am given the opportunity to refactor, but if its just piling more tech debt on top of crap code it gets pretty demotivating.
  • dimitar 7y ago
    What if the code is written in Delphi, committed in SVN and you have to figure out how to build it? True story..
    • hyperman1 7y ago
      Thats pretty tame. I once got a bug like: Some contractor wrote this, got mgmt to get a new, insane deployment procedure scripted and deploy it on completely the wrong server. Some days it produces a report, other days it swallows 16GB and dies. After he left we wrote the contents of his hard drive to this stack of CDs, and they are scratchy enough to have data loss. Of course the prod executable differs from all variants of code found on the CDs. It turns out to be a custom reporting framework for producing exactly 1 report. For extra speed, it starts 100 threads but doesnt have any synchronisation. Which turns out not to matter as they are all fighting for 1 DB connection. You are not allowed to touch prod directly, but have to get some unix guy on the phone so far to recover logs, executable, and config. And as that guy has to support this mess, he hates your guts by association.
      • pnutjam 7y ago
        Can confirm, I've been the Unix guy.
    • matfil 7y ago
      I actually quite enjoy the true mysteries that nobody has touched for years. It's a situation where you're expected to slink off into a corner and swear quietly for a few days, and nearly-certain hero status if you pull it off. The more frustrating situation it needing to jump in and make a one-off fix to something that is at least notionally "modern". These can be just as impenetrable, but you have to hold your tongue much more (especially if some of the developers are still around), and there's generally a lot less kudos for sorting things out. Personal "favourite": debugging stuff that's virtually impossible to build locally "...because we've got this great CD pipeline".
  • test1235 7y ago
    >I love to look through old code, add missing testcases and fix minor issues. You've been working with decent code, in that case. The legacy stuff I come across isn't even testable without massive refactoring, even if the company allows you to do that in the first place. Also, deprecated libraries for which there is no upgrade, which leads to further framework support issues (e.g. you can't upgrade X 'cos it doesn't support Y where swapping out X would take siginificant effort). The worst problem I come across is spaghetti code where the business logic is ridiculously hard to follow, and it's not entirely clear if something is intentional or not, till you inevitably break it, and get an angry email from someone you didn't even know used the system.
    • Jach 7y ago
      I like the definition of legacy code as untested code, since it means your fresh pile of untested crap is immediately legacy code someone will have to deal with later -- often yourself. Refactoring (for testing or not) is something you can do without the company 'allowing' it or adding 'dedicated trust work time' to the schedule. Sure, it does need buy-in from whoever reviews/signs off your commits if they bother to ask why you did that thing, and in pathological cases you'll have to keep a test suite to yourself / a local environment, but the social issues seem less of a barrier than people just throwing their hands up at perceived technical issues. I like recommending Feathers' Working Effectively With Legacy Code since it serves as a technical reference of solutions to the usual technical challenges/complaints that hang people up.
  • proverbialbunny 7y ago
    You're lucky. Some people will try to get you fired if you touch their code. Some managers see modifying an existing code base as a waste of time. In some work environments you can easily take ownership of a project, and some not.
    • driverdan 7y ago
      Why would you willingly work in such a hostile environment?
      • proverbialbunny 7y ago
        I don't.
  • croo 7y ago
    Missing test cases? You mean like the very first test and the junit dependency? I love that feeling too :)
• spease 7y ago
  This can be good or bad depending on how it’s done. If the new code addresses the same issues as the old code more succinctly, or if it can cut out some unused code that the original solution had, then it can be a net improvement. Eg refactoring an NIH solution to use new libraries that didn’t exist originally. If it’s replacing sound code with a half-thought-out implementation, maybe not so great.
• rjzzleep 7y ago
  Newest technology isn't always the problem. The problem is always the choices and incentives you have. All projects I lead always have the aspect of how are you going to maintain it when I'm gone. So I tend to "force" the project owner to spend money/time on simplifying unmaintainable parts of the infrastructure. They're always happy about these changes after the fact however. It's also the opposite of what most big consulting firms do, because they do want to maintain a steady revenue stream from their clients.
• distant_hat 7y ago
  It is because maintain and fix doesn't raise your profile as much. People do what they are incentivized to do. If there were extra points at review time for maintenance, people would refactor old code all the time.
• CalRobert 7y ago
  At your annual review, "I kept our rickety leaning tower of tech debt from falling over" doesn't sounds as good as "I deployed blah blah systems to (do whatever)". This is bad, of course, but it's generally how things go.
  • mszkoda 7y ago
    Even more so, when you're interviewing somewhere else you (and usually they) want to talk about new things you deployed or new systems you created, not how you maintained this boring code base for 2 years.
    • rantwasp 7y ago
      it’s hard explaining and assessing work done in maintenance. interviews are also really stressful.
      • therealdrag0 7y ago
        I've had good results highlighting performance and security-holes I've fixed. Engineers also sympathize/appreciate with improvements I've done just for my own sanity, like making the build pipeline faster. None of these where things I did because someone told me to, they where things I do because I cared. Meanwhile plenty of my peers ignored the problems or couldn't be bothered to fix them.
• Aeolun 7y ago
  Hah, I have the opposite. New devs come in and want to refactor everything. We should make our whole react codebase functional instead of class based, because it’s clearer. Cue 10 interdependent hooks.
  • Dude2029 7y ago
    That's what you get for choosing react. Many ways to do the same, many alternative packages. Extra complexity layers to just bind rest json to a control. Good CV booster though.
    • Aeolun 7y ago
      That’s basically any front-end framework though.
• Infinitesimus 7y ago
  It's a game of incentives. I might enjoy making systems cleaner and more maintainable but if the incentives for my next promotion are "lead new large scale project to ship something a few times and maybe you can get a promo", why bother? It's probably one of the worst parts of large-ish organizations
• ElFitz 7y ago
  The only company where I was tasked with "maintaining and fixing" the code of others, parts of the codebase where 90s' blackboxes nobody would touch with a 10 ft stick, and simply setting up the proper environnement to reproduce a bug could take up to two days. Then some weird error relating to some obscure fax sending module reconverted into an email templating service would creep up somehow and have to be fixed before I could go back to debugging. So, yeah. I churned, and went on to build new things.
• noobiemcfoob 7y ago
  New devs almost certainly shouldn't be given maintenance and repair tasks. How can someone know all of the business logic and needs a given solution provides within a month of starting? This problem is because the old guard wants to move on from the problems they created. They want to play with new toys. So they hire new devs to do the work they don't want and "free" themselves for greenfield development (i.e. the exact opposite of how it should be managed).
  • Haga 7y ago
    To then repeat the same mistakes with new tech.
  • rantwasp 7y ago
    that’s okay. they get brought in and save the day when the new guy messes up. the classic definition of win-win: you’re off the monster you created and doing things with exciting technology AND you are a hero for saving everyone on a regular basis.
    • noobiemcfoob 7y ago
      Oh, this hurts so hard. I'm going to go cry now.
    • AndyMcConachie 7y ago
      It sucks being the old hand as well. I was once sent to a customer's site to fix a deployment that had taken too long. It was for a telco product that required a couple racks of UNIX machines and Cisco routers. They had sent a new guy with essentially no training and he had not done a bad job. He was just new and needed time to get up to speed. When I started working with him he clearly knew what he was doing. But we got everything working 1 day after I showed up, because I had been deploying this product for a few years already. Management basically praised me and shat on the new guy. I felt like crap and took new guy aside. We became friends, but this hurt his review later on.
  • close04 7y ago
    > New devs almost certainly shouldn't be given maintenance and repair tasks. This would just massively increase churn. Old guys get sick of doing the same old crap especially when seeing the new guys get all the good stuff. So it increases the likelihood that people will just move around a lot more often in order to build that "new stuff". Eventually you'll have lots of companies saturated with "new stuff" that's no longer so new and nobody to maintain it because everybody knows the second you're too old in the company you get saddled with maintenance tasks. > the old guard wants to move on from the problems they created Just because it's old doesn't mean it's a problem. It still has to be maintained though, with higher effort since the technology may be outdated. Even the best designed systems become a chore to maintain when you have to do it for 10 years instead of doing anything new.