In a complicated legacy codebase, do you refactor or keep writing dirty hacks?
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?
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.
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.
This got me laugh so hard.
Always refactor.
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!
Unless you get proper rewarded and recognized, otherwise don't bother
Good point. Beyond buy-in, there should be some sort of incentive. It can be tough work.
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.
What's to stop SDEs from doing unnecessary refactorings all the time?
Refactorings are low profit. You should be playing the deprecate and rebuild game.
Hence Hangouts, Allo, Duo, Hangouts Chat, Hangouts Meet, Google Messages
Yep. You get it.
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.
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
Just remember this: no good deed goes unpunished.
"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."
^Holy fuck this is my life right now