4

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?

Improve this question
7
  • 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, 2015 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, 2015 at 12:41
  • 6
    @MartinBarker That's one heck of a sentence! :O
    – Jane S
    Sep 11, 2015 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, 2015 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, 2015 at 14:31

3 Answers 3

Reset to default
5

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?

Improve this answer
5
  • "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, 2015 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, 2015 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, 2015 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, 2015 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, 2015 at 13:10
2

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".

Improve this answer
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .