Maintaining a massive project with many unfamiliar technologies as a solo developer

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
4
down vote

favorite












Context: there is an internal project developed by 5 developers (including me) over a couple years; now the other guys have left, including the PM. Management of the project is passed to another PM, who was working on a related project. He doesn't pay much attention to my project, because he is busy with his own, it's kind of a rush situation there... or may be other reasons. The old PM is supposed to "support" the project, but he doesn't pay much attention either. He's difficult to reach.



And now I'm getting a letter from testers asking "when will the bugs get fixed"? More then half of them aren't in my code, and it's not even the platform I know well, so I just don't have any idea. The code is enormous, and so far I counted these languages: C#, PowerShell, Scala, Bash, Ruby, Go, Groovy, Python, JavaScript



So... how do I answer this letter? How do I deal with the whole situation?







share|improve this question


















  • 8




    Direct them to the manager who is supposed to be supporting the project. If they come back to you again, direct them again to the manager who is supposed to be supporting the project. Ad nauseum :)
    – Jane S♦
    Sep 11 '15 at 12:34






  • 2




    unfortunate side effect of take over a project as a sole developer you can't think of it as my code his code it's all your teams code no matter how big or small your team becomes as a competent developer you should be able to work with some one else code to fix bug's but if the Project Manager is not aware of the scale of the problem he can't do anything to fix it if he then is unwilling to help do his job and manage the project go to his boss and say look this is not working he's not able to manage both projects as I have received no management from him i have a list of task and no priorities
    – Martin Barker
    Sep 11 '15 at 12:41






  • 6




    @MartinBarker That's one heck of a sentence! :O
    – Jane S♦
    Sep 11 '15 at 12:43






  • 1




    @JaneS yeah there we're a couple of point that needed making but was not an answer and im dyslexic and these boxes don't help :)
    – Martin Barker
    Sep 11 '15 at 12:46






  • 1




    When you are looking for the best technical approach rather than a social solution to your problem, you might get better answers on programmers.stackexchange.com
    – Philipp
    Sep 11 '15 at 14:31

















up vote
4
down vote

favorite












Context: there is an internal project developed by 5 developers (including me) over a couple years; now the other guys have left, including the PM. Management of the project is passed to another PM, who was working on a related project. He doesn't pay much attention to my project, because he is busy with his own, it's kind of a rush situation there... or may be other reasons. The old PM is supposed to "support" the project, but he doesn't pay much attention either. He's difficult to reach.



And now I'm getting a letter from testers asking "when will the bugs get fixed"? More then half of them aren't in my code, and it's not even the platform I know well, so I just don't have any idea. The code is enormous, and so far I counted these languages: C#, PowerShell, Scala, Bash, Ruby, Go, Groovy, Python, JavaScript



So... how do I answer this letter? How do I deal with the whole situation?







share|improve this question


















  • 8




    Direct them to the manager who is supposed to be supporting the project. If they come back to you again, direct them again to the manager who is supposed to be supporting the project. Ad nauseum :)
    – Jane S♦
    Sep 11 '15 at 12:34






  • 2




    unfortunate side effect of take over a project as a sole developer you can't think of it as my code his code it's all your teams code no matter how big or small your team becomes as a competent developer you should be able to work with some one else code to fix bug's but if the Project Manager is not aware of the scale of the problem he can't do anything to fix it if he then is unwilling to help do his job and manage the project go to his boss and say look this is not working he's not able to manage both projects as I have received no management from him i have a list of task and no priorities
    – Martin Barker
    Sep 11 '15 at 12:41






  • 6




    @MartinBarker That's one heck of a sentence! :O
    – Jane S♦
    Sep 11 '15 at 12:43






  • 1




    @JaneS yeah there we're a couple of point that needed making but was not an answer and im dyslexic and these boxes don't help :)
    – Martin Barker
    Sep 11 '15 at 12:46






  • 1




    When you are looking for the best technical approach rather than a social solution to your problem, you might get better answers on programmers.stackexchange.com
    – Philipp
    Sep 11 '15 at 14:31













up vote
4
down vote

favorite









up vote
4
down vote

favorite











Context: there is an internal project developed by 5 developers (including me) over a couple years; now the other guys have left, including the PM. Management of the project is passed to another PM, who was working on a related project. He doesn't pay much attention to my project, because he is busy with his own, it's kind of a rush situation there... or may be other reasons. The old PM is supposed to "support" the project, but he doesn't pay much attention either. He's difficult to reach.



And now I'm getting a letter from testers asking "when will the bugs get fixed"? More then half of them aren't in my code, and it's not even the platform I know well, so I just don't have any idea. The code is enormous, and so far I counted these languages: C#, PowerShell, Scala, Bash, Ruby, Go, Groovy, Python, JavaScript



So... how do I answer this letter? How do I deal with the whole situation?







share|improve this question














Context: there is an internal project developed by 5 developers (including me) over a couple years; now the other guys have left, including the PM. Management of the project is passed to another PM, who was working on a related project. He doesn't pay much attention to my project, because he is busy with his own, it's kind of a rush situation there... or may be other reasons. The old PM is supposed to "support" the project, but he doesn't pay much attention either. He's difficult to reach.



And now I'm getting a letter from testers asking "when will the bugs get fixed"? More then half of them aren't in my code, and it's not even the platform I know well, so I just don't have any idea. The code is enormous, and so far I counted these languages: C#, PowerShell, Scala, Bash, Ruby, Go, Groovy, Python, JavaScript



So... how do I answer this letter? How do I deal with the whole situation?









share|improve this question













share|improve this question




share|improve this question








edited Sep 11 '15 at 13:38









Lilienthal♦

53.9k36183218




53.9k36183218










asked Sep 11 '15 at 12:27









XenoMind

7161815




7161815







  • 8




    Direct them to the manager who is supposed to be supporting the project. If they come back to you again, direct them again to the manager who is supposed to be supporting the project. Ad nauseum :)
    – Jane S♦
    Sep 11 '15 at 12:34






  • 2




    unfortunate side effect of take over a project as a sole developer you can't think of it as my code his code it's all your teams code no matter how big or small your team becomes as a competent developer you should be able to work with some one else code to fix bug's but if the Project Manager is not aware of the scale of the problem he can't do anything to fix it if he then is unwilling to help do his job and manage the project go to his boss and say look this is not working he's not able to manage both projects as I have received no management from him i have a list of task and no priorities
    – Martin Barker
    Sep 11 '15 at 12:41






  • 6




    @MartinBarker That's one heck of a sentence! :O
    – Jane S♦
    Sep 11 '15 at 12:43






  • 1




    @JaneS yeah there we're a couple of point that needed making but was not an answer and im dyslexic and these boxes don't help :)
    – Martin Barker
    Sep 11 '15 at 12:46






  • 1




    When you are looking for the best technical approach rather than a social solution to your problem, you might get better answers on programmers.stackexchange.com
    – Philipp
    Sep 11 '15 at 14:31













  • 8




    Direct them to the manager who is supposed to be supporting the project. If they come back to you again, direct them again to the manager who is supposed to be supporting the project. Ad nauseum :)
    – Jane S♦
    Sep 11 '15 at 12:34






  • 2




    unfortunate side effect of take over a project as a sole developer you can't think of it as my code his code it's all your teams code no matter how big or small your team becomes as a competent developer you should be able to work with some one else code to fix bug's but if the Project Manager is not aware of the scale of the problem he can't do anything to fix it if he then is unwilling to help do his job and manage the project go to his boss and say look this is not working he's not able to manage both projects as I have received no management from him i have a list of task and no priorities
    – Martin Barker
    Sep 11 '15 at 12:41






  • 6




    @MartinBarker That's one heck of a sentence! :O
    – Jane S♦
    Sep 11 '15 at 12:43






  • 1




    @JaneS yeah there we're a couple of point that needed making but was not an answer and im dyslexic and these boxes don't help :)
    – Martin Barker
    Sep 11 '15 at 12:46






  • 1




    When you are looking for the best technical approach rather than a social solution to your problem, you might get better answers on programmers.stackexchange.com
    – Philipp
    Sep 11 '15 at 14:31








8




8




Direct them to the manager who is supposed to be supporting the project. If they come back to you again, direct them again to the manager who is supposed to be supporting the project. Ad nauseum :)
– Jane S♦
Sep 11 '15 at 12:34




Direct them to the manager who is supposed to be supporting the project. If they come back to you again, direct them again to the manager who is supposed to be supporting the project. Ad nauseum :)
– Jane S♦
Sep 11 '15 at 12:34




2




2




unfortunate side effect of take over a project as a sole developer you can't think of it as my code his code it's all your teams code no matter how big or small your team becomes as a competent developer you should be able to work with some one else code to fix bug's but if the Project Manager is not aware of the scale of the problem he can't do anything to fix it if he then is unwilling to help do his job and manage the project go to his boss and say look this is not working he's not able to manage both projects as I have received no management from him i have a list of task and no priorities
– Martin Barker
Sep 11 '15 at 12:41




unfortunate side effect of take over a project as a sole developer you can't think of it as my code his code it's all your teams code no matter how big or small your team becomes as a competent developer you should be able to work with some one else code to fix bug's but if the Project Manager is not aware of the scale of the problem he can't do anything to fix it if he then is unwilling to help do his job and manage the project go to his boss and say look this is not working he's not able to manage both projects as I have received no management from him i have a list of task and no priorities
– Martin Barker
Sep 11 '15 at 12:41




6




6




@MartinBarker That's one heck of a sentence! :O
– Jane S♦
Sep 11 '15 at 12:43




@MartinBarker That's one heck of a sentence! :O
– Jane S♦
Sep 11 '15 at 12:43




1




1




@JaneS yeah there we're a couple of point that needed making but was not an answer and im dyslexic and these boxes don't help :)
– Martin Barker
Sep 11 '15 at 12:46




@JaneS yeah there we're a couple of point that needed making but was not an answer and im dyslexic and these boxes don't help :)
– Martin Barker
Sep 11 '15 at 12:46




1




1




When you are looking for the best technical approach rather than a social solution to your problem, you might get better answers on programmers.stackexchange.com
– Philipp
Sep 11 '15 at 14:31





When you are looking for the best technical approach rather than a social solution to your problem, you might get better answers on programmers.stackexchange.com
– Philipp
Sep 11 '15 at 14:31











3 Answers
3






active

oldest

votes

















up vote
5
down vote



accepted











How do I deal with the whole situation?




Talk to your (new) manager. He's probably not paying much attention to your project because he assumes that everything is going well. That won't change unless you notify him about it. While normally it should have been his responsibility to inform you of how he wants you to proceed day-to-day and how and when to escalate problems, you should definitely ask him about it now that you're in a bind.



Not having written the code yourself is not a valid reason for not maintaining it. A lot of the code you're now responsible for will be unfamiliar to you but since you've been on the project for multiple years that will go for most of your own code as well. If the project is using technologies that you simply don't know, then you should either be trained in them or if that's not an option another solution should be found. Whether that's bringing the old PM back in or getting additional developers on the project is for your manager to decide. If you have other concerns beyond this related to project size or workload those are also issues to discuss with your manager.



Note that the role of the old PM will presumably just be to consult on technical matters if both you and your new manager are stumped so it's normal that he's not taking an active interest.



As for the request from the testers, wait to reply until you've talked to your manager. You should then have some idea of the time line for the rest of the project and can give them at least some indication for when the bugs will be resolved. If you still have doubts, ask your manager how he'd like you to handle communication with the testers.



One final caveat: when reporting problems to your manager you should also try to provide solutions. As an example:




I'm now solely responsible for maintaining this project but I'm unfamiliar with large parts of the code. To effectively address issues I'll probably need to spend a few days going through the entire application, is that okay?








The testers reported an issue with the Flux Capacitor that Old PM developed but I've only worked with the TARDIS routines before. Can I forward those issues to him or should I try to learn the Flux technology as well and only request his help when I'm stuck?







share|improve this answer






















  • "is not a valid reason for not maintaining it": Nobody can know everything. It's a different OS, different languages. Dealing with all this is far over my head.
    – XenoMind
    Sep 11 '15 at 12:49










  • "Not having written the code yourself is not a valid reason for not maintaining it" both of us read that bit and though the same there i just dropped it into a comment
    – Martin Barker
    Sep 11 '15 at 12:49






  • 5




    @XenoMind if thats the case you dont have the skill set and you need to inform your manager ASAP before it looks bad on you. the worst thing you can do is be worried about how you look for saying you dont have the skills and not tell any one as it will just get raised that your not doing anything inform some one who can get a member of staff that is able to do them skills in to fix the problems
    – Martin Barker
    Sep 11 '15 at 12:50











  • @Martin Barker, and "how to present this situation to the PM propely" is another tough question. "A few days" is just not enough. The code is enormous, and so far I counted these languages: C#, PowerShell, Scala, Bash, Ruby, Go, Groovy, Python, JavaScript
    – XenoMind
    Sep 11 '15 at 12:59







  • 2




    @XenoMind I already addressed what to do if learning the new tech is not an option in my first revision but I've expanded my answer a bit. You should add that information to your question though. Note that the examples I give are for generic situations. If the technology gap is as great as you describe then it's probably impossible for you to be the only maintainer for this project, but you'll need to work out what you can and can't do with your manager.
    – Lilienthal♦
    Sep 11 '15 at 13:10


















up vote
2
down vote













Break it down into smaller, measurable tasks.



Do you know when you can start investigating the bugs? If so, say "I'll be able to start investigation on Date X. Once I have reviewed them I can start the estimation process."



Ask for prioritization of the bugs. Then investigate in order of priority.



Once you have reviewed the highest priority issues, and have some idea of the effort to fix, you can offer that. "So, I have reviewed the Blockers and it looks like it will take Y weeks to fix those".



Then repeat process for the next highest priority.



Communication is the key. Estimates provided in smaller, prioritized chunks lets management and team members adjust their plans accordingly. Of course they won't be 100% accurate, but it's much more useful than "I don't know, I'll let you know when I'm done".






share|improve this answer



























    up vote
    0
    down vote













    The question is not quite clear whether you are looking for a polite way to tell your co-workers and superiors what you told us or whether you are looking for a more technical solution.



    It's very unlikely that nobody knows that a team of 5 was reduced to 1 and nobody blamed you for being late, so I think there is no reason for the social approach yet. And as you say it's an internal project, it's likely support and sales isn't going to kill you if your estimations are not that good.



    How to deal with the situation:



    Divide and Conquer.



    First group all bugs into two or three chunks: Those likely within the code you are familiar with, those in code you are not familiar with and maybe those, where you don't see any chance of being able to fix the bug within a decent time.



    Then group the bugs by how easy they are to reproduce. Is the bug reproducible without problems? Is it a bug that occurs once every three weeks?



    Then estimate the required time per group per bug. For example, an easily reproducible bug in your own code should be fixed in a day and if you have 30 of these, you can estimate it will take 30 days. Maybe one bug takes three days for a bigger rewrite, but on other days you can fix two bugs per day. It will even out.



    Finally sort the list by bug priority. Send your project manager and the testers the list, telling them that this is your roadmap and that the "can't do" bugs won't be fixed, unless specifically requested by the project manager.



    Then start working on the bugs, keep track how much time you actually need per group, update your estimations and the roadmap once per month and you should be good to go. Anyone with real objections will let you know.






    share|improve this answer




















      Your Answer







      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "423"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: false,
      noModals: false,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      noCode: true, onDemand: false,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );








       

      draft saved


      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f54276%2fmaintaining-a-massive-project-with-many-unfamiliar-technologies-as-a-solo-develo%23new-answer', 'question_page');

      );

      Post as a guest

























      StackExchange.ready(function ()
      $("#show-editor-button input, #show-editor-button button").click(function ()
      var showEditor = function()
      $("#show-editor-button").hide();
      $("#post-form").removeClass("dno");
      StackExchange.editor.finallyInit();
      ;

      var useFancy = $(this).data('confirm-use-fancy');
      if(useFancy == 'True')
      var popupTitle = $(this).data('confirm-fancy-title');
      var popupBody = $(this).data('confirm-fancy-body');
      var popupAccept = $(this).data('confirm-fancy-accept-button');

      $(this).loadPopup(
      url: '/post/self-answer-popup',
      loaded: function(popup)
      var pTitle = $(popup).find('h2');
      var pBody = $(popup).find('.popup-body');
      var pSubmit = $(popup).find('.popup-submit');

      pTitle.text(popupTitle);
      pBody.html(popupBody);
      pSubmit.val(popupAccept).click(showEditor);

      )
      else
      var confirmText = $(this).data('confirm-text');
      if (confirmText ? confirm(confirmText) : true)
      showEditor();


      );
      );






      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      5
      down vote



      accepted











      How do I deal with the whole situation?




      Talk to your (new) manager. He's probably not paying much attention to your project because he assumes that everything is going well. That won't change unless you notify him about it. While normally it should have been his responsibility to inform you of how he wants you to proceed day-to-day and how and when to escalate problems, you should definitely ask him about it now that you're in a bind.



      Not having written the code yourself is not a valid reason for not maintaining it. A lot of the code you're now responsible for will be unfamiliar to you but since you've been on the project for multiple years that will go for most of your own code as well. If the project is using technologies that you simply don't know, then you should either be trained in them or if that's not an option another solution should be found. Whether that's bringing the old PM back in or getting additional developers on the project is for your manager to decide. If you have other concerns beyond this related to project size or workload those are also issues to discuss with your manager.



      Note that the role of the old PM will presumably just be to consult on technical matters if both you and your new manager are stumped so it's normal that he's not taking an active interest.



      As for the request from the testers, wait to reply until you've talked to your manager. You should then have some idea of the time line for the rest of the project and can give them at least some indication for when the bugs will be resolved. If you still have doubts, ask your manager how he'd like you to handle communication with the testers.



      One final caveat: when reporting problems to your manager you should also try to provide solutions. As an example:




      I'm now solely responsible for maintaining this project but I'm unfamiliar with large parts of the code. To effectively address issues I'll probably need to spend a few days going through the entire application, is that okay?








      The testers reported an issue with the Flux Capacitor that Old PM developed but I've only worked with the TARDIS routines before. Can I forward those issues to him or should I try to learn the Flux technology as well and only request his help when I'm stuck?







      share|improve this answer






















      • "is not a valid reason for not maintaining it": Nobody can know everything. It's a different OS, different languages. Dealing with all this is far over my head.
        – XenoMind
        Sep 11 '15 at 12:49










      • "Not having written the code yourself is not a valid reason for not maintaining it" both of us read that bit and though the same there i just dropped it into a comment
        – Martin Barker
        Sep 11 '15 at 12:49






      • 5




        @XenoMind if thats the case you dont have the skill set and you need to inform your manager ASAP before it looks bad on you. the worst thing you can do is be worried about how you look for saying you dont have the skills and not tell any one as it will just get raised that your not doing anything inform some one who can get a member of staff that is able to do them skills in to fix the problems
        – Martin Barker
        Sep 11 '15 at 12:50











      • @Martin Barker, and "how to present this situation to the PM propely" is another tough question. "A few days" is just not enough. The code is enormous, and so far I counted these languages: C#, PowerShell, Scala, Bash, Ruby, Go, Groovy, Python, JavaScript
        – XenoMind
        Sep 11 '15 at 12:59







      • 2




        @XenoMind I already addressed what to do if learning the new tech is not an option in my first revision but I've expanded my answer a bit. You should add that information to your question though. Note that the examples I give are for generic situations. If the technology gap is as great as you describe then it's probably impossible for you to be the only maintainer for this project, but you'll need to work out what you can and can't do with your manager.
        – Lilienthal♦
        Sep 11 '15 at 13:10















      up vote
      5
      down vote



      accepted











      How do I deal with the whole situation?




      Talk to your (new) manager. He's probably not paying much attention to your project because he assumes that everything is going well. That won't change unless you notify him about it. While normally it should have been his responsibility to inform you of how he wants you to proceed day-to-day and how and when to escalate problems, you should definitely ask him about it now that you're in a bind.



      Not having written the code yourself is not a valid reason for not maintaining it. A lot of the code you're now responsible for will be unfamiliar to you but since you've been on the project for multiple years that will go for most of your own code as well. If the project is using technologies that you simply don't know, then you should either be trained in them or if that's not an option another solution should be found. Whether that's bringing the old PM back in or getting additional developers on the project is for your manager to decide. If you have other concerns beyond this related to project size or workload those are also issues to discuss with your manager.



      Note that the role of the old PM will presumably just be to consult on technical matters if both you and your new manager are stumped so it's normal that he's not taking an active interest.



      As for the request from the testers, wait to reply until you've talked to your manager. You should then have some idea of the time line for the rest of the project and can give them at least some indication for when the bugs will be resolved. If you still have doubts, ask your manager how he'd like you to handle communication with the testers.



      One final caveat: when reporting problems to your manager you should also try to provide solutions. As an example:




      I'm now solely responsible for maintaining this project but I'm unfamiliar with large parts of the code. To effectively address issues I'll probably need to spend a few days going through the entire application, is that okay?








      The testers reported an issue with the Flux Capacitor that Old PM developed but I've only worked with the TARDIS routines before. Can I forward those issues to him or should I try to learn the Flux technology as well and only request his help when I'm stuck?







      share|improve this answer






















      • "is not a valid reason for not maintaining it": Nobody can know everything. It's a different OS, different languages. Dealing with all this is far over my head.
        – XenoMind
        Sep 11 '15 at 12:49










      • "Not having written the code yourself is not a valid reason for not maintaining it" both of us read that bit and though the same there i just dropped it into a comment
        – Martin Barker
        Sep 11 '15 at 12:49






      • 5




        @XenoMind if thats the case you dont have the skill set and you need to inform your manager ASAP before it looks bad on you. the worst thing you can do is be worried about how you look for saying you dont have the skills and not tell any one as it will just get raised that your not doing anything inform some one who can get a member of staff that is able to do them skills in to fix the problems
        – Martin Barker
        Sep 11 '15 at 12:50











      • @Martin Barker, and "how to present this situation to the PM propely" is another tough question. "A few days" is just not enough. The code is enormous, and so far I counted these languages: C#, PowerShell, Scala, Bash, Ruby, Go, Groovy, Python, JavaScript
        – XenoMind
        Sep 11 '15 at 12:59







      • 2




        @XenoMind I already addressed what to do if learning the new tech is not an option in my first revision but I've expanded my answer a bit. You should add that information to your question though. Note that the examples I give are for generic situations. If the technology gap is as great as you describe then it's probably impossible for you to be the only maintainer for this project, but you'll need to work out what you can and can't do with your manager.
        – Lilienthal♦
        Sep 11 '15 at 13:10













      up vote
      5
      down vote



      accepted







      up vote
      5
      down vote



      accepted







      How do I deal with the whole situation?




      Talk to your (new) manager. He's probably not paying much attention to your project because he assumes that everything is going well. That won't change unless you notify him about it. While normally it should have been his responsibility to inform you of how he wants you to proceed day-to-day and how and when to escalate problems, you should definitely ask him about it now that you're in a bind.



      Not having written the code yourself is not a valid reason for not maintaining it. A lot of the code you're now responsible for will be unfamiliar to you but since you've been on the project for multiple years that will go for most of your own code as well. If the project is using technologies that you simply don't know, then you should either be trained in them or if that's not an option another solution should be found. Whether that's bringing the old PM back in or getting additional developers on the project is for your manager to decide. If you have other concerns beyond this related to project size or workload those are also issues to discuss with your manager.



      Note that the role of the old PM will presumably just be to consult on technical matters if both you and your new manager are stumped so it's normal that he's not taking an active interest.



      As for the request from the testers, wait to reply until you've talked to your manager. You should then have some idea of the time line for the rest of the project and can give them at least some indication for when the bugs will be resolved. If you still have doubts, ask your manager how he'd like you to handle communication with the testers.



      One final caveat: when reporting problems to your manager you should also try to provide solutions. As an example:




      I'm now solely responsible for maintaining this project but I'm unfamiliar with large parts of the code. To effectively address issues I'll probably need to spend a few days going through the entire application, is that okay?








      The testers reported an issue with the Flux Capacitor that Old PM developed but I've only worked with the TARDIS routines before. Can I forward those issues to him or should I try to learn the Flux technology as well and only request his help when I'm stuck?







      share|improve this answer















      How do I deal with the whole situation?




      Talk to your (new) manager. He's probably not paying much attention to your project because he assumes that everything is going well. That won't change unless you notify him about it. While normally it should have been his responsibility to inform you of how he wants you to proceed day-to-day and how and when to escalate problems, you should definitely ask him about it now that you're in a bind.



      Not having written the code yourself is not a valid reason for not maintaining it. A lot of the code you're now responsible for will be unfamiliar to you but since you've been on the project for multiple years that will go for most of your own code as well. If the project is using technologies that you simply don't know, then you should either be trained in them or if that's not an option another solution should be found. Whether that's bringing the old PM back in or getting additional developers on the project is for your manager to decide. If you have other concerns beyond this related to project size or workload those are also issues to discuss with your manager.



      Note that the role of the old PM will presumably just be to consult on technical matters if both you and your new manager are stumped so it's normal that he's not taking an active interest.



      As for the request from the testers, wait to reply until you've talked to your manager. You should then have some idea of the time line for the rest of the project and can give them at least some indication for when the bugs will be resolved. If you still have doubts, ask your manager how he'd like you to handle communication with the testers.



      One final caveat: when reporting problems to your manager you should also try to provide solutions. As an example:




      I'm now solely responsible for maintaining this project but I'm unfamiliar with large parts of the code. To effectively address issues I'll probably need to spend a few days going through the entire application, is that okay?








      The testers reported an issue with the Flux Capacitor that Old PM developed but I've only worked with the TARDIS routines before. Can I forward those issues to him or should I try to learn the Flux technology as well and only request his help when I'm stuck?








      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Sep 11 '15 at 12:54

























      answered Sep 11 '15 at 12:42









      Lilienthal♦

      53.9k36183218




      53.9k36183218











      • "is not a valid reason for not maintaining it": Nobody can know everything. It's a different OS, different languages. Dealing with all this is far over my head.
        – XenoMind
        Sep 11 '15 at 12:49










      • "Not having written the code yourself is not a valid reason for not maintaining it" both of us read that bit and though the same there i just dropped it into a comment
        – Martin Barker
        Sep 11 '15 at 12:49






      • 5




        @XenoMind if thats the case you dont have the skill set and you need to inform your manager ASAP before it looks bad on you. the worst thing you can do is be worried about how you look for saying you dont have the skills and not tell any one as it will just get raised that your not doing anything inform some one who can get a member of staff that is able to do them skills in to fix the problems
        – Martin Barker
        Sep 11 '15 at 12:50











      • @Martin Barker, and "how to present this situation to the PM propely" is another tough question. "A few days" is just not enough. The code is enormous, and so far I counted these languages: C#, PowerShell, Scala, Bash, Ruby, Go, Groovy, Python, JavaScript
        – XenoMind
        Sep 11 '15 at 12:59







      • 2




        @XenoMind I already addressed what to do if learning the new tech is not an option in my first revision but I've expanded my answer a bit. You should add that information to your question though. Note that the examples I give are for generic situations. If the technology gap is as great as you describe then it's probably impossible for you to be the only maintainer for this project, but you'll need to work out what you can and can't do with your manager.
        – Lilienthal♦
        Sep 11 '15 at 13:10

















      • "is not a valid reason for not maintaining it": Nobody can know everything. It's a different OS, different languages. Dealing with all this is far over my head.
        – XenoMind
        Sep 11 '15 at 12:49










      • "Not having written the code yourself is not a valid reason for not maintaining it" both of us read that bit and though the same there i just dropped it into a comment
        – Martin Barker
        Sep 11 '15 at 12:49






      • 5




        @XenoMind if thats the case you dont have the skill set and you need to inform your manager ASAP before it looks bad on you. the worst thing you can do is be worried about how you look for saying you dont have the skills and not tell any one as it will just get raised that your not doing anything inform some one who can get a member of staff that is able to do them skills in to fix the problems
        – Martin Barker
        Sep 11 '15 at 12:50











      • @Martin Barker, and "how to present this situation to the PM propely" is another tough question. "A few days" is just not enough. The code is enormous, and so far I counted these languages: C#, PowerShell, Scala, Bash, Ruby, Go, Groovy, Python, JavaScript
        – XenoMind
        Sep 11 '15 at 12:59







      • 2




        @XenoMind I already addressed what to do if learning the new tech is not an option in my first revision but I've expanded my answer a bit. You should add that information to your question though. Note that the examples I give are for generic situations. If the technology gap is as great as you describe then it's probably impossible for you to be the only maintainer for this project, but you'll need to work out what you can and can't do with your manager.
        – Lilienthal♦
        Sep 11 '15 at 13:10
















      "is not a valid reason for not maintaining it": Nobody can know everything. It's a different OS, different languages. Dealing with all this is far over my head.
      – XenoMind
      Sep 11 '15 at 12:49




      "is not a valid reason for not maintaining it": Nobody can know everything. It's a different OS, different languages. Dealing with all this is far over my head.
      – XenoMind
      Sep 11 '15 at 12:49












      "Not having written the code yourself is not a valid reason for not maintaining it" both of us read that bit and though the same there i just dropped it into a comment
      – Martin Barker
      Sep 11 '15 at 12:49




      "Not having written the code yourself is not a valid reason for not maintaining it" both of us read that bit and though the same there i just dropped it into a comment
      – Martin Barker
      Sep 11 '15 at 12:49




      5




      5




      @XenoMind if thats the case you dont have the skill set and you need to inform your manager ASAP before it looks bad on you. the worst thing you can do is be worried about how you look for saying you dont have the skills and not tell any one as it will just get raised that your not doing anything inform some one who can get a member of staff that is able to do them skills in to fix the problems
      – Martin Barker
      Sep 11 '15 at 12:50





      @XenoMind if thats the case you dont have the skill set and you need to inform your manager ASAP before it looks bad on you. the worst thing you can do is be worried about how you look for saying you dont have the skills and not tell any one as it will just get raised that your not doing anything inform some one who can get a member of staff that is able to do them skills in to fix the problems
      – Martin Barker
      Sep 11 '15 at 12:50













      @Martin Barker, and "how to present this situation to the PM propely" is another tough question. "A few days" is just not enough. The code is enormous, and so far I counted these languages: C#, PowerShell, Scala, Bash, Ruby, Go, Groovy, Python, JavaScript
      – XenoMind
      Sep 11 '15 at 12:59





      @Martin Barker, and "how to present this situation to the PM propely" is another tough question. "A few days" is just not enough. The code is enormous, and so far I counted these languages: C#, PowerShell, Scala, Bash, Ruby, Go, Groovy, Python, JavaScript
      – XenoMind
      Sep 11 '15 at 12:59





      2




      2




      @XenoMind I already addressed what to do if learning the new tech is not an option in my first revision but I've expanded my answer a bit. You should add that information to your question though. Note that the examples I give are for generic situations. If the technology gap is as great as you describe then it's probably impossible for you to be the only maintainer for this project, but you'll need to work out what you can and can't do with your manager.
      – Lilienthal♦
      Sep 11 '15 at 13:10





      @XenoMind I already addressed what to do if learning the new tech is not an option in my first revision but I've expanded my answer a bit. You should add that information to your question though. Note that the examples I give are for generic situations. If the technology gap is as great as you describe then it's probably impossible for you to be the only maintainer for this project, but you'll need to work out what you can and can't do with your manager.
      – Lilienthal♦
      Sep 11 '15 at 13:10













      up vote
      2
      down vote













      Break it down into smaller, measurable tasks.



      Do you know when you can start investigating the bugs? If so, say "I'll be able to start investigation on Date X. Once I have reviewed them I can start the estimation process."



      Ask for prioritization of the bugs. Then investigate in order of priority.



      Once you have reviewed the highest priority issues, and have some idea of the effort to fix, you can offer that. "So, I have reviewed the Blockers and it looks like it will take Y weeks to fix those".



      Then repeat process for the next highest priority.



      Communication is the key. Estimates provided in smaller, prioritized chunks lets management and team members adjust their plans accordingly. Of course they won't be 100% accurate, but it's much more useful than "I don't know, I'll let you know when I'm done".






      share|improve this answer
























        up vote
        2
        down vote













        Break it down into smaller, measurable tasks.



        Do you know when you can start investigating the bugs? If so, say "I'll be able to start investigation on Date X. Once I have reviewed them I can start the estimation process."



        Ask for prioritization of the bugs. Then investigate in order of priority.



        Once you have reviewed the highest priority issues, and have some idea of the effort to fix, you can offer that. "So, I have reviewed the Blockers and it looks like it will take Y weeks to fix those".



        Then repeat process for the next highest priority.



        Communication is the key. Estimates provided in smaller, prioritized chunks lets management and team members adjust their plans accordingly. Of course they won't be 100% accurate, but it's much more useful than "I don't know, I'll let you know when I'm done".






        share|improve this answer






















          up vote
          2
          down vote










          up vote
          2
          down vote









          Break it down into smaller, measurable tasks.



          Do you know when you can start investigating the bugs? If so, say "I'll be able to start investigation on Date X. Once I have reviewed them I can start the estimation process."



          Ask for prioritization of the bugs. Then investigate in order of priority.



          Once you have reviewed the highest priority issues, and have some idea of the effort to fix, you can offer that. "So, I have reviewed the Blockers and it looks like it will take Y weeks to fix those".



          Then repeat process for the next highest priority.



          Communication is the key. Estimates provided in smaller, prioritized chunks lets management and team members adjust their plans accordingly. Of course they won't be 100% accurate, but it's much more useful than "I don't know, I'll let you know when I'm done".






          share|improve this answer












          Break it down into smaller, measurable tasks.



          Do you know when you can start investigating the bugs? If so, say "I'll be able to start investigation on Date X. Once I have reviewed them I can start the estimation process."



          Ask for prioritization of the bugs. Then investigate in order of priority.



          Once you have reviewed the highest priority issues, and have some idea of the effort to fix, you can offer that. "So, I have reviewed the Blockers and it looks like it will take Y weeks to fix those".



          Then repeat process for the next highest priority.



          Communication is the key. Estimates provided in smaller, prioritized chunks lets management and team members adjust their plans accordingly. Of course they won't be 100% accurate, but it's much more useful than "I don't know, I'll let you know when I'm done".







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Sep 11 '15 at 12:43









          Laconic Droid

          2,1112813




          2,1112813




















              up vote
              0
              down vote













              The question is not quite clear whether you are looking for a polite way to tell your co-workers and superiors what you told us or whether you are looking for a more technical solution.



              It's very unlikely that nobody knows that a team of 5 was reduced to 1 and nobody blamed you for being late, so I think there is no reason for the social approach yet. And as you say it's an internal project, it's likely support and sales isn't going to kill you if your estimations are not that good.



              How to deal with the situation:



              Divide and Conquer.



              First group all bugs into two or three chunks: Those likely within the code you are familiar with, those in code you are not familiar with and maybe those, where you don't see any chance of being able to fix the bug within a decent time.



              Then group the bugs by how easy they are to reproduce. Is the bug reproducible without problems? Is it a bug that occurs once every three weeks?



              Then estimate the required time per group per bug. For example, an easily reproducible bug in your own code should be fixed in a day and if you have 30 of these, you can estimate it will take 30 days. Maybe one bug takes three days for a bigger rewrite, but on other days you can fix two bugs per day. It will even out.



              Finally sort the list by bug priority. Send your project manager and the testers the list, telling them that this is your roadmap and that the "can't do" bugs won't be fixed, unless specifically requested by the project manager.



              Then start working on the bugs, keep track how much time you actually need per group, update your estimations and the roadmap once per month and you should be good to go. Anyone with real objections will let you know.






              share|improve this answer
























                up vote
                0
                down vote













                The question is not quite clear whether you are looking for a polite way to tell your co-workers and superiors what you told us or whether you are looking for a more technical solution.



                It's very unlikely that nobody knows that a team of 5 was reduced to 1 and nobody blamed you for being late, so I think there is no reason for the social approach yet. And as you say it's an internal project, it's likely support and sales isn't going to kill you if your estimations are not that good.



                How to deal with the situation:



                Divide and Conquer.



                First group all bugs into two or three chunks: Those likely within the code you are familiar with, those in code you are not familiar with and maybe those, where you don't see any chance of being able to fix the bug within a decent time.



                Then group the bugs by how easy they are to reproduce. Is the bug reproducible without problems? Is it a bug that occurs once every three weeks?



                Then estimate the required time per group per bug. For example, an easily reproducible bug in your own code should be fixed in a day and if you have 30 of these, you can estimate it will take 30 days. Maybe one bug takes three days for a bigger rewrite, but on other days you can fix two bugs per day. It will even out.



                Finally sort the list by bug priority. Send your project manager and the testers the list, telling them that this is your roadmap and that the "can't do" bugs won't be fixed, unless specifically requested by the project manager.



                Then start working on the bugs, keep track how much time you actually need per group, update your estimations and the roadmap once per month and you should be good to go. Anyone with real objections will let you know.






                share|improve this answer






















                  up vote
                  0
                  down vote










                  up vote
                  0
                  down vote









                  The question is not quite clear whether you are looking for a polite way to tell your co-workers and superiors what you told us or whether you are looking for a more technical solution.



                  It's very unlikely that nobody knows that a team of 5 was reduced to 1 and nobody blamed you for being late, so I think there is no reason for the social approach yet. And as you say it's an internal project, it's likely support and sales isn't going to kill you if your estimations are not that good.



                  How to deal with the situation:



                  Divide and Conquer.



                  First group all bugs into two or three chunks: Those likely within the code you are familiar with, those in code you are not familiar with and maybe those, where you don't see any chance of being able to fix the bug within a decent time.



                  Then group the bugs by how easy they are to reproduce. Is the bug reproducible without problems? Is it a bug that occurs once every three weeks?



                  Then estimate the required time per group per bug. For example, an easily reproducible bug in your own code should be fixed in a day and if you have 30 of these, you can estimate it will take 30 days. Maybe one bug takes three days for a bigger rewrite, but on other days you can fix two bugs per day. It will even out.



                  Finally sort the list by bug priority. Send your project manager and the testers the list, telling them that this is your roadmap and that the "can't do" bugs won't be fixed, unless specifically requested by the project manager.



                  Then start working on the bugs, keep track how much time you actually need per group, update your estimations and the roadmap once per month and you should be good to go. Anyone with real objections will let you know.






                  share|improve this answer












                  The question is not quite clear whether you are looking for a polite way to tell your co-workers and superiors what you told us or whether you are looking for a more technical solution.



                  It's very unlikely that nobody knows that a team of 5 was reduced to 1 and nobody blamed you for being late, so I think there is no reason for the social approach yet. And as you say it's an internal project, it's likely support and sales isn't going to kill you if your estimations are not that good.



                  How to deal with the situation:



                  Divide and Conquer.



                  First group all bugs into two or three chunks: Those likely within the code you are familiar with, those in code you are not familiar with and maybe those, where you don't see any chance of being able to fix the bug within a decent time.



                  Then group the bugs by how easy they are to reproduce. Is the bug reproducible without problems? Is it a bug that occurs once every three weeks?



                  Then estimate the required time per group per bug. For example, an easily reproducible bug in your own code should be fixed in a day and if you have 30 of these, you can estimate it will take 30 days. Maybe one bug takes three days for a bigger rewrite, but on other days you can fix two bugs per day. It will even out.



                  Finally sort the list by bug priority. Send your project manager and the testers the list, telling them that this is your roadmap and that the "can't do" bugs won't be fixed, unless specifically requested by the project manager.



                  Then start working on the bugs, keep track how much time you actually need per group, update your estimations and the roadmap once per month and you should be good to go. Anyone with real objections will let you know.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Sep 14 '15 at 17:05









                  John Hammond

                  4,3071329




                  4,3071329






















                       

                      draft saved


                      draft discarded


























                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f54276%2fmaintaining-a-massive-project-with-many-unfamiliar-technologies-as-a-solo-develo%23new-answer', 'question_page');

                      );

                      Post as a guest

















































































                      Comments

                      Popular posts from this blog

                      What does second last employer means? [closed]

                      Installing NextGIS Connect into QGIS 3?

                      One-line joke