The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
My former boss wrote a very large application which is over 20 years old with hundreds of thousands of lines of code. He would spend many hours off-book, doing maintenance and making improvements. It was a labor of love for him.
I inherited this code to provide solutions in projects. Am I obligated to pick up the maintenance of this code?
If the codebase is still something that's in use in your company then you are probably going to be required to maintain it at least so far as is required to keep up that usage. As for anything that would fall into "labor of love" territory, probably not.
Basically work on it at work, as directed by your boss - anything else is at your discretion (and I probably wouldn't bother personally)
There are two parts of the question that needs answering, as I see:
Part 1:
Am I obligated to pick up the maintenance of this code [....] ?
You answered yourself, "I inherited this code" (I take this as in professional capacity), so the responsibilities are yours, too. Whatever requirement comes that needs a change, you have to work on that.
[...] outside of project work?
No, you're not. As you mentioned, it was a "labor of love" to your ex-boss, is it the same to you? If the answer would have been yes, you would not have been asking this question here, so the answer is no, both the cases.
To clarify: "Maintenance" is not analogous to "change-the-code-in-my-free-time-at-will-because-I-can". It is a well-defined process, driven by a requirement (internal or external) and has a clear versioning of changes (preferably with a change-log).
This is a decision best left to whoever your current manager is. As an employee, your job is to spend the time you have doing whatever provides the most value to the business. It is your manager's job to figure out what that is.
It sounds like this is a very complex project that is going to take you quite a bit of time to learn and work on. You need to work with your manager to figure out if this is the best thing for you to be working on, and if so, how to balance that work with your current responsibilities.
Your old boss may have spent a lot of time working on this application, but that does not necessarily mean you have to. Your new manager should be the one to decide if this is what you should now be working on.
No, you're not.
Maintain only as and when required by either something being broken or something needing to be enhanced.
There's really no need for you to waste until hours learning and maintaining this code base for little measurable benefit.
Have in the back of your mind that time spent on this code base must be profitable for the company. Only touch it when there's profit to be made from it.
The fact that this was your predecessor's pet project doesn't mean that it has to be yours too.
First question you should find an answer to: is this code valuable to the company? Does it make money? If it stops working, will the company lose money?
If the answer to the question is "yes", then the second question which needs to be answered is "are you the best person to maintain this code?".
If the answer to that question is also yes, then you should maintain that code.
Now, when it comes to answering the questions and deciding whether you have to work on it, you can be completely junior about it and leave everything to others (your manager, other management, seniors) to decide. Or you can be more senior by taking responsibility and tell your manager "This piece of code is valuable, I think it's in the best interest of the company if I dedicate some time maintaining it. What do you think?"
