In a complicated legacy codebase, do you refactor or keep writing dirty hacks?

Micro Focus / Eng chmod777
May 13 17 Comments

I’m working on a bug and know of a solution. One solution involves refactoring HUGE chunks of code (some of which I don’t understand but it depends on the code that I need to change, I think?) that could potentially break a lot of things, take significantly longer than a single sprint, and quite frankly is above my pay grade. It’s just fucking painful and soul crushing. On the other hand I could write a dirty hack to get things working, then cross it off my list and hope I never have to come back to that part of the codebase. I feel like in an ideal world it would be great to do the right thing but in practice people have shitting on this code for nearly two decades so who cares if I add more shit on top of it?

comments

Want to comment? LOG IN or SIGN UP
TOP 17 Comments
  • Apple industry
    I usually go with hacks unless I think those hacks will considerably affect my productivity in the long run. Refactoring a large codebase is a pain and you will end up breaking stuff unless it’s a team effort with proper code reviews and quality assurance work. So fuck that and remember this: every hour spent refactoring is one hour not spent leetcoding.
    May 13 1
    • Amazon / Eng pinkcat
      This got me laugh so hard.
      May 13
  • Facebook ⭕w⭕
    Just remember this: no good deed goes unpunished.
    May 13 2
    • Microsoft / Eng bebK16
      "Since you're the last one who touched this code, you're now the owner and the expert. All requests in this space will now come to you, but you will never have time to properly refactor. Good luck."
      May 13
    • Micro Focus / Eng chmod777
      OP
      ^Holy fuck this is my life right now
      May 13
  • Until the performance review process values refactoring code on the same level as shipping new code for "impact," SWEs will always be incentivized to do quick and dirty hacks. Pass that dirty hot potato along.
    May 13 1
    • Amazon PotatoSale
      What's to stop SDEs from doing unnecessary refactorings all the time?
      May 13
  • Workday ypKT26
    Unless you get proper rewarded and recognized, otherwise don't bother
    May 13 1
    • Intel / Eng XTiI86
      Good point. Beyond buy-in, there should be some sort of incentive. It can be tough work.
      May 13
  • Intel / Eng XTiI86
    I agree, these can be tough calls.

    You're probably right about being above your pay grade. In a sense. Specifically, the decision to refactor is likely not just your own. Definitely need to make sure there is buy-in, preferabbly from a manager who is willing to go to bat for you, in case things dont go completely smoothly (assume it won't).

    What I will say if that the hack is that dirty, don't put it in just because *you* won't look at it again. If you expect *anyone* to have to deal with please, from one engineer to another, don't leave it a mess. You never know, you might even be the chosen one to dig through it next time!
    May 13 0
  • Google / Eng
    sqrt(-1)

    Google Eng

    BIO
    Top Contributor or GTFO
    sqrt(-1)more
    Refactorings are low profit. You should be playing the deprecate and rebuild game.
    May 13 2
    • Hence Hangouts, Allo, Duo, Hangouts Chat, Hangouts Meet, Google Messages
      May 13
    • Google / Eng
      sqrt(-1)

      Google Eng

      BIO
      Top Contributor or GTFO
      sqrt(-1)more
      Yep. You get it.
      May 13
  • Uber UberPool
    Present options to manager in a detailed living design doc
    (1) refactor, huge cost, huge time sync, future proof
    (2) quick hack, no cost, fast, may break in future

    Manager will beg for (2), have manager sign off on design doc, in writing, publicly viewable, cc his manager

    Do the hack, then quietly leave the team
    May 13 0
  • Bring up the issue of the problematic codebase with the team. You should probably fix the bug with a hack for now, but consider the refactor/rewrite a separate longer term project which will improve developer productivity and reduce maintenance time/cost.
    May 13 0
  • Microsoft lolololo
    Just hack it. If you refactor and it works nobody will give you credit. But if it breaks something you will be blamed for it.
    May 13 0
  • Amazon scarF4ce
    Always refactor.
    May 13 0

Salary
Comparison

    Real time salary information from verified employees