Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
sariel84473yI hope you have a 5 year ROI document.
Managers typically only care about the cost and what the rate of return is.
"If it's not broke, don't fix it." -- every mother fuckin manager -
@sariel hm, not true.
It depends more on how well structured the approach is and how realistic it is.
It's easy throwing an approach als refactoring makes things brr in.
Less easy and usually far more time intensive:
- investigating common used libraries and frameworks
- investigate upcoming language / library / framework changes
- investigate OS releases / deprecations / EOL of "non-project" software changes and implications
- looking at future tickets / epics etc.
- etc etc
Throwing everything in the mixer and create a proposal with a timeline of when / how changes could / must be done and proper reasoning (e.g. must - EOL / no more releases / doesn't support necessary security standards) including benefits and contra of the refactoring.
If you wanna earn extra points, alternative solutions and possible migration steps / migration planning, factoring in and laying out possible risks like down time.
It's less the question of what should be refactored or what's the cost, more the question of how to squeeze the most profit out of it aka "looking at the bigger picture". -
@asgs Not really.
It's rather sad that someone expects that someone else should do all the thinking despite not being in topic.
I'm against non technical management, but still whenever I have to come up with such plans I really want to do ... very violent excessively brutal stuff ... with some devs.
Most devs really think only as far as told.
Give someone the task "please plan this carefully till next week" with a bullet point list of things you expire and you'll most likely get a pile of garbage...
(Explicitly telling dev they should take the necessary time off)
You'll then have the joyful task as a manager and plan ahead with a lot of variables, in worst case doing one on one interviews with employees to evaluate skill set etc.
Simply put: You'll have to put in an awful lot of work and even when asking for help you can be pretty sure noone wants to help.
But when the point has come where the plan is set in motion - well, then everybody can suddenly scream and moan how shitty everything is and why noone asked them beforehand... -
asgs112753y@IntrusionCM fuck others and let's refactor if there is benefit in doing whatever portion of the codebase is relevant to the situation on hand
I'm going to talk to my supervisor about redoing their code base.
It will take time, it will suck a bit but I think the long term investment in doing this right will be worth it.
Wish me luck in convincing him 😂🤞
random
it's all trash
please let me clean up this mess