|
I think the basic truth to work off of here is: "Shit got real." Yes, you can step away, in the figurative and literal sense. In many possible worlds this may even be the best plan, if you have no real agency over the code. And you got lied to. It'd hardly be the first time someone has been convinced that the work would be cooler than it is. But -- you also have to decide if this is an opportunity in disguise. Stories of folks who gradually build ownership over the creaky "legacy" codebase and polish it up with Sisyphean refactoring, until it shames the "rewrite", are out there, and they're real. On the other hand, fixing the legacy code may be one of the hardest things you can do in software architecture. There's no sense of joyous freedom to it, just correcting of old mistakes. But if you did that, and published documentation to evidence what you did and how, lots of folks would want you - and not necessarily for the task of fixing their own crusty code. So there is an opportunity here, if you can find a way to sneak it through the management, which has surely decided on the balance sheet that the code is a "deprecated asset" and will not want to hear about new ideas. In fact, to maintain it you don't want to present anything as a "new" - you have the much harder task of justifying every small change as an opportunity to improve the debuggability - to get the callstack down from 20 deep to 19 deep, to remove a superfluous parameter, to improve turnaround times, to reduce the code size by a few lines, or something similarly miniscule, but which might add up over time into real understanding. |
Never seen it in practice. Is this a real thing?